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Zusammenfassung 


Bei der statischen Programmanalyse geht es darum, Eigenschaften von 
Programmen abzuleiten, ohne sie auszuführen. Zwei wichtige statische 
Programmanalysetechniken sind zum einen die Datenflussanalyse auf Kon- 
trollflussgraphen und zum anderen Slicing auf Programmabhängigkeitsgraphen 
(PAG). In dieser Arbeit berichte ich über Anwendungen von Slicing und 
Programmabhängigkeitsgraphen in der Softwaresicherheit. Außerdem 
schlage ich ein Analyse-Rahmenwerk vor, welches Datenflussanalyse auf 
Kontrollflussgraphen und Slicing auf Programmabhängigkeitsgraphen 
verallgemeinert. Mit einem solchen Rahmenwerk lassen sich neue PAG- 
basierte Analysen systematisch ableiten, die über Slicing hinausgehen. 


Eine wichtige Anwendung von PAG-basiertem Slicing liegt in der Soft- 
waresicherheit, genauer in der Informationsflusskontrolle. Bei dieser geht es 
darum sicherzustellen, dass ein gegebenes Programm keine vertraulichen 
Informationen über öffentliche Kanäle preisgibt bzw. öffentliche Einga- 
ben keine kritischen Berechnungen beeinflussen können. Der Lehrstuhl 
Programmierparadigmen am KIT entwickelt seit einiger Zeit Joana, ein 
Werkzeug zur Informationsflusskontrolle für Java, das unter anderem 
auf Programmabhängigkeitsgraphen und Slicing basiert. Von 2011 bis 
2017 war der Lehrstuhl am Schwerpunktprogramm 1496 „Zuverlässig 
sichere Softwaresysteme” (engl. Reliably Secure Software Systems, RS?) 
der Deutschen Forschungsgemeinschaft (DFG) beteiligt. 

Im ersten Teil dieser Arbeit gebe ich einen Überblick über Beiträge des 
Lehrstuhls zu RS?, an denen ich beteiligt war. Diese Beiträge umfassen zum 
einen die Erweiterung eines mit PAG-basierten Techniken überprüfbaren 
Informationsflusskontrollkriteriums für nebenläufige Programme, und 
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zum anderen eine Reihe von Anwendungen von Joana in der Softwaresi- 
cherheit. 


Im zweiten Teil meiner Doktorarbeit schlage ich vor, Datenflussanalysen 
auf Kontrollflussgraphen und Slicing auf Programmabhängigkeitsgraphen 
zu einer gemeinsamen, verallgemeinerten Analysetechnik zu vereinheitli- 
chen. Eine solche Vereinheitlichung ermöglicht beispielsweise neue Ana- 
lysen auf PAGs, die über bestehende PAG-basierte Ansätze hinausgehen. 
Darüber hinaus können für die Instanzen der allgemeinen Analysetechnik 
bestimmte formale Garantien gegeben werden, welche die Korrektheits- 
argumente, wie sie u.a. für bestehende PAG-basierte Analysen gegeben 
wurden, vereinfachen. 

Zunächst stelle ich ein allgemeines Graphmodell sowie ein allgemeines A- 
nalyse-Rahmenwerk vor und zeige, dass sich sowohl Datenflussanalyse auf 
Kontrollflussgraphen als auch Slicing auf Programmabhängigkeitsgraphen 
darin ausdrücken lassen. 

Anschließend zeige ich, dass sich Instanzen des allgemeinen Analyse- 
Rahmenwerkes durch Ungleichungssysteme beschreiben lassen. Hierbei 
greife ich auf klassische Ansätze zurück und passe diese geeignet an. 

Ich gebe außerdem Algorithmen zur Lösung der zuvor aufgestellten Un- 
gleichungssysteme an. Diese kombinieren klassische Lösungsalgorithmen 
für Datenflussanalysen mit einer Erreichbarkeitsanalyse. 

Schließlich beschreibe ich eine Instanziierung der allgemeinen Analysetech- 
nik für Programmabhängigkeitsgraphen. Ich stelle eine Implementierung 
in Joana vor und evaluiere diese anhand von realen Programmabhängig- 
keitsgraphen und einiger Beispielanalysen. 


Die Hauptthesen meiner Arbeit lauten wie folgt: 


1. PAG-basierte Informationsflusskontrolle ist nützlich, praktisch anwend- 
bar und relevant. 


2. Datenflussanalyse kann systematisch auf Programmabhängigkeitsgra- 
phen angewendet werden. 


3. Datenflussanalyse auf Programmabhängigkeitsgraphen ist praktisch 
durchführbar. 
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Abstract 


Static program analysis is concerned with deriving properties of computer 
programs without executing them. Two important static program analysis 
techniques are data-flow analysis on control-flow graphs and slicing on program 
dependence graphs (PDGs). In this thesis, I report on applications of slicing 
and program dependence graphs to software security. Moreover, I propose 
a framework that generalizes both data-flow analysis on control-flow 
graphs and slicing on program dependence graphs. Such a framework 
enables to systematically derive data-flow-like analyses on program de- 
pendence graphs that go beyond slicing. 


One important application of PDG-based slicing lies in the field of software 
security, more specifically in information flow control. The goal of information 
flow control is to verify that a given program does not leak confidential 
information to public channels, or, respectively, that public input cannot 
influence critical computations. 

The programming paradigms group at KIT develops Joana, a PDG-based 
information flow control tool for Java that employs program dependence 
graphs and slicing. From 2011 to 2017, our group participated in the 
priority program “Reliably Secure Software Systems” (RS, SPP 1496) of 
the German Research Foundation (DFG). 

In the first part of this dissertation I give an overview of the contributions of 
the programming paradigms group to RS? in which I participated. These 
contributions include, on the one hand, the extension of an information 
flow control criterion for concurrent programs that can be checked with 
PDG-based techniques, and, on the other hand, a number of applications 
of Joana in software security. 
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Abstract 


In the second part of my dissertation, I present a unification of data flow 
analysis on control flow graphs and slicing on program dependence graphs 
into a common, general analysis technique. Such a unification enables 
new analyses on PDGs that go beyond existing PDG-based approaches. In 
addition, for instances of the general analysis technique, certain formal 
guarantees can be given for instances of the general analysis technique, 
which simplify correctness proofs such as those given for existing PDG- 
based analyses. 

First, I introduce a general graph model as well as a general analysis 
framework and show that data-flow analysis on control-flow graphs as 
well as slicing on program dependence graphs can be expressed in this 
framework. 

Then, I show that instances of the general analysis framework can be 
described by monotone constraint systems. For this, I resort to traditional 
approaches and adapt them appropriately. 

I also present algorithms for solving the constraint systems set up earlier. 
These algorithms combine traditional solution approaches for data flow 
analyses with a reachability analysis. 

Finally, I describe an instantiation of the general analysis technique for 
program dependence graphs: I present an implementation in Joana and 
evaluate it using real programs and a selection of example analyses. 

In summary, the main theses of my dissertation are: 


1. PDG-based information flow control is useful, practically applicable 
and relevant. 


2. Data-flow analysis can be systematically applied to program dependence 
graphs. 


3. Data-flow analysis on PDGs can be practically conducted. 
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Introduction 


Program analysis is a branch of computer science that is concerned with 
the derivation of a given computer program’s properties. Static program 
analysis [130, 76], or static analysis for short, is a sub-branch of program 
analysis that considers techniques to derive properties of a given program 
without executing it. 

This thesis is located within the field of static program analysis. More 
specifically, it considers automatic static program analysis techniques, i.e. 
static analyses that can execute without human interaction. 

Two notable static analysis techniques, which are important to this thesis, 
are data-flow analysis [101] and program slicing [165, 166, 58]. The basic idea 
of data-flow analysis is to analyze how a given program transforms data 
along its executions. Slicing was originally developed to aid programmers 
in debugging. Its goal is, given a program p, to extract a sub-program of p 
that behaves equivalently to p with respect to a given observation. Such a 
sub-program is also called a slice. 

Both data-flow analysis and program slicing can be conducted on a graph 
representation of the given program. Data-flow analysis typically uses 
the program’s control-flow graph [12], whereas an established approach 
to program slicing employs the program dependence graph (PDG) [58, 93, 
137]. These two graph representations concentrate on different aspects of 
a program. 

The control-flow graph focuses on the actual executions of the program 
and how control is transferred between its statements. Its nodes can be 
thought of as the program’s statements, while an edge between a statement 
sı and another statement s) means that s2 may be executed directly after 
sı. A program dependence graph on the other hand materializes the 
dependencies between the program’s variables and statements. There are 
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1 x = input(); 
2 if (x > 42) { 
3 y=17; 
4 } else { 

5 y = 23; 
6 } 
7 Zz 


= X; 


(a) (c) 


Figure 1.1: A small code snippet (a) with its control-flow graph (b) and its program 
dependence graph (c) — node labels correspond to line numbers; in 
Figure 1.1c, data and control dependencies are represented by solid and 
dashed edges, respectively. 


two major kinds of dependencies. A data dependency arises between two 
statements sı and 52 if sı writes a value that sọ reads. A control dependency 
describes that s; controls whether sz is executed or not. Figure 1.1 shows 
an example for control-flow graphs and program dependence graphs. 
As has been shown by Ferrante et al. [58], PDGs can be used for program 
slicing: Giving a node n in a PDG G, called slicing criterion, the (PDG-based) 
backwards slice of n consists of all nodes from which n is reachable in 
G. Analogously, the forward slice of n consists of all nodes which are 
reachable from n. 

Both control-flow graphs and program dependence graphs can also be 
used to represent programs with multiple procedures. These variants and 
the analyses that process them are called interprocedural [154, 93]. 


1.1 Applications to Software Security 


The first main part of this thesis is concerned with applications of static 
analysis techniques such as PDGs and slicing to software security. The 
goal of static analysis in software security (which I will call static security 
analysis in the following) is usually to analyze a given program or system 
with respect to some desirable security property. 

In software security, there are three desirable classes of properties of a given 
system. Confidentiality means that no sensitive information is disclosed 
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1 int h = inputPIN(); // HIGH 
2 print(h); // LOW 

3 if (h > 4711) { 

4 print("0K"); // LOW 

5 } else { 

6 print ("FAIL") // LOW 

7} 

8 


print("A”) // LOW 


Figure 1.2: Simple examples for illegal information flows 


to a public or untrusted channel, integrity describes the property that no 
untrusted input can influence critical computations and, finally, availability 
states that data is always accessible if necessary [17]. This thesis focuses on 
confidentiality and integrity, which both can be generically formulated as 
an information-flow property. Basically, such a property demands that high 
input cannot influence low output. In the following, I briefly explain this in 
more detail. Information-flow properties assume that a program contains 
(information) sources and (information) sinks. Sources are typically points in 
the program where data is imported from the outside, whereas sinks are 
points in the program where it emits output, e.g. where it exports data to 
the outside. An information flow between a source and a sink manifests 
itself if a change in the data that a source imports can lead to a change 
in the output that a sink generates. A typical information-flow property 
demands that the given program does not contain any illegal information 
flows. In order to distinguish between legal and illegal information flows, 
sources and sinks are usually labeled with some form of sensitivity level, 
in the simplest case high and low. An information flow is called illegal if it 
starts in a high source and ends in a low sink. 

Simple examples for legal and illegal information flows are shown in 
Figure 1.2. On the one hand, this code snippet contains illegal information 
flows from the high source in line 1 to the low sinks in lines 2, 4, and 6, 
respectively. On the other hand, no information flows from line 1 to line 8. 
The class of static security analyses that are concerned with verifying 
information-flow properties is also called information flow control [53]. 

As Snelting et al. [157] noted, slicing can be used to perform static in- 
formation flow control. The basic idea is as follows: A (backwards) slice 
of a program with respect to a public sink contains all parts from which 
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information may flow to the given sink. Therefore, if such a slice does not 
contain any secret source, there is no information flow between any secret 
source and the public sink. 

Moreover, as mentioned before, program dependence graphs turn out to 
be an appropriate program representation to perform slicing. In particular, 
they reduce the task of computing a slice to a form of graph reachability. 
A slice can be obtained by traversing the graph and collecting all nodes 
that are connected to a given node via a chain of edges. 

Extending upon these ideas, the programming paradigms group! at KIT 
developed Joana [104], an information flow control tool for Java. First, 
given a Java application, Joana builds a program dependence graph. Then, 
the user can annotate sources and sinks on this graph and use Joana to 
perform various slicing-based static information flow control checks. 
From 2011 to 2017, the programming paradigms group participated in the 
priority program “Reliably Secure Software Systems” (RS?) of the German 
Research Foundation (DFG). The main thesis of RS? was that classical 
mechanism-based approaches to software security like authentication and 
access control need to be complemented with property-oriented approaches 
such as information flow control [4]. 

In chapter 4 of this thesis, I will give an overview of the achievements of 
the programming paradigms group within the RS? project. Our group 
extended the theoretical foundations of Joana, participated in a number of 
collaborations, and applied Joana to various scenarios within the field of 
software security. 


1.2 Systematic Approaches to Advanced 
Information Flow Analysis 


The second part of my thesis is concerned with a generalization of both 
data-flow analysis on control-flow graphs and slicing-based techniques on 
program dependence graphs. One motivation for this is that a generalized 
analysis framework enables data-flow-like analyses on program depend- 
ence graphs and therefore can extend the toolkit of PDG-based tools like 
Joana by a family of powerful analyses. Moreover, such a generalization 
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is also theoretically interesting because it clarifies the relation between the 
two techniques, enables the re-use of formal guarantees and simplifies the 
development of new slicing-based techniques. 

While they have different purposes and have developed independently, 
data-flow analysis on control-flow graphs and slicing on program depend- 
ence graphs share a fairly large amount of similarities. Both operate on a 
graph that represents the program to be analyzed and obtain their result by 
some form of propagation along an appropriate set of paths on the given 
graph. Moreover, both techniques face the same challenge for programs 
with multiple procedures. To analyze such programs properly, it is crucial 
to only consider paths where procedure calls return to the sites that they 
were actually called from. Data-flow analyses are usually conducted in 
order to derive properties of the set of a given program’s executions by 
propagating pieces of data along abstract representations of these execu- 
tions. Traditionally, they are expressed using a generic framework, for 
which general formal guarantees can be given [101, 154, 106]. Moreover, 
they can be systematically derived from program semantics [45]. In this 
sense, data-flow analysis can be thought of as executing the program 
using an abstraction of the real program semantics that concentrates only 
on those aspects of interest. Thus, data-flow analysis can represent and 
process fairly complex data. 

Slicing on program dependence graphs is a form of reachability analysis. 
While it appears to be expressible as a very simple data-flow-like analysis - 
the information that slicing propagates is “this node is reachable”? - slicing 
can in fact not be cast as an instance of ordinary data-flow frameworks. 
This is because slicing requires a richer setting than such frameworks. 

In the following, I briefly discuss the setting for data-flow analysis and 
then contrast it with the one for slicing. 

Firstly, interprocedural data-flow analyses track the flow of data beginning 
in a main procedure from which every node is assumed to be reachable. 
Secondly, because data-flow analyses are supposed to consider abstractions 
of actual program executions, they naturally only follow descending control- 
flow paths that begin in entry of the main procedure. A control-flow path 
mt is called descending, if n only contains returns from procedures for which 
mt also contains the corresponding call. 


>This will be detailed in chapter 3. 
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In summary, interprocedural data-flow analyses on control-flow graphs 
traverse descending paths that begin in the entry of the main procedure 
and thus reach every node in the graph. 

In contrast, PDG-based slicing operates with different assumptions. 
While data-flow analysis on control-flow graphs always starts propagation 
with a fixed node for which it is known per se that every node is reachable 
from it, PDG-based slicing starts from an arbitrary node of interest. Naturally, 
it cannot be assumed that this node is reachable in the PDG from the entry 
of main. Moreover, the node for which the slice is to be computed can be 
situated in some arbitrary part of the PDG. Hence, in order to compute a 
complete slice for this node, it is necessary to not only consider descending 
paths, but also paths that contain unmatched returns. 

To sum up, the difference between the two techniques can be described best 
as follows: While data-flow analysis assumes that every node is reachable 
and computes a value for it, the task of PDG-based slicing is to compute the 
very reachability information that data-flow analysis assumes. 

Hence, a generalization of both data-flow analysis on control-flow graphs 
and PDG-based slicing has to account for the two aspects that the two 
techniques lay their respective focus on: On the one hand, it needs to 
determine which nodes are reachable (like slicing does) and on the other 
hand, it needs to compute some result for every reachable node (like 
data-flow analysis does). 

The second part of my thesis develops this idea. I propose a generaliz- 
ation of both data-flow analysis and slicing. Firstly, my generalization 
comprises a general graph model that covers both control-flow graphs 
and program dependence graphs. Secondly, it provides a framework for 
generalized data-flow analysis on this graph model. With this framework, 
both data-flow analyses and slicing-based analyses are expressible. My 
generalized data-flow framework combines the strengths of both classical 
data-flow analysis and PDG-based slicing. Like data-flow analysis, it 
allows to express data with complex structure. Like PDG-based slicing, it 
takes the node from which propagation is supposed to start as additional 
input and also follows paths with unmatched returns. I will show that 
classical approaches to interprocedural data-flow analysis are transferable 
to my generalized framework. Moreover, I present general algorithms 
that compute solutions to generalized data-flow analysis problems. These 
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algorithms combine the classical solution algorithms for data-flow ana- 
lyses [102, 130] with reachability analysis and a well-known approach to 
interprocedural slicing [93, 137]. 


1.3 Main Theses and Contributions 


The main theses of this dissertation are: 


Main Thesis 1: PDG-based information flow control is useful, prac- 
tically applicable and relevant. Ireport on several applications of Joana 
within the field of security analysis. These applications were the result of 
my collaborations with other research groups within the RS? project. 


Main Thesis 2: Data-flow analysis can be systematically applied to 
program dependence graphs. 


e I propose a general graph model and - building upon this model 
-a general data-flow analysis framework. In this framework, both 
classic data-flow analyses on interprocedural control-flow graphs 
and slicing-based analyses on interprocedural program dependence 
graphs can be expressed. 


I present two approaches with which instances of the proposed 
framework can be solved. These approaches are based on the 
approaches that were proposed by Sharir and Pnueli [154] for classic 
data-flow analysis problems and use monotone constraint systems 
to describe solutions. 


I describe generic solution algorithms for the presented approaches. 
These algorithms combine the classic worklist-based algorithm for 
solving monotone constraint systems and hence classic data-flow 
analysis problems with a reachability analysis. 


e I give formal characterizations of the results of my algorithms and 
prove correctness results. 


e I demonstrate that my solution algorithms can be refined in such a 
way that they can be reduced to the well-known algorithms proposed 
for context-sensitive slicing (for an appropriate framework instance). 
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Main Thesis 3: Data-flow analysis on PDGs can be practically con- 
ducted. Within the scope of this work, I have implemented my algorithms 
in Joana and have evaluated them on real program dependence graphs. 
Thus, I demonstrate that the presented approaches not only enjoy pleasant 
theoretical properties but are also practically feasible and useful. 


1.4 Organization of This Thesis 


The organization of this thesis is depicted in Figure 1.3. 

Chapter 2 compiles the basic notions and theories that are relevant through- 
out this thesis. In particular, it gives an introduction to basic order and 
fixed-point theory and, based upon that, a presentation of monotone 
constraint systems and the classical worklist-based algorithm to solve such 
systems. Monotone constraint systems form the theoretic foundation of 
data-flow analysis as it is presented and used in this thesis. The solving 
algorithm serves as the basis for algorithms that are developed in later 
chapters. 

After the general foundations were laid in chapter 2, chapter 3 prepares for 
the two main topics of this thesis. Its first part, which ranges from 3.1 to 
3.3, gives an introduction to several concepts and techniques employed in 
static program analysis. Specifically, it introduces both data-flow analysis 
on interprocedural control-flow graphs and context-sensitive slicing on 
interprocedural program dependence graphs. Moreover, it introduces 
information flow control and discusses its relation to slicing. Finally, 
section 3.4 prepares the reader for chapter 4. It gives an overview of 
Joana, the information flow control tool developed by the programming 
paradigms group. In particular, it explains various data-flow analysis 
techniques that Joana employs in order to properly compute program 
dependence graphs for object-oriented languages such as Java. 

After chapter 3 has provided the necessary program analysis background, 
chapter 4 reparis on the contributions of the programming paradigms 
group to RS”. These contributions consist of (a) advancements of PDG- 
based checks for concurrent non-interference and (b) applications of Joana 
to various scenarios and collaborations. 

The chapters following chapter 4 lay out the second main topic of my thesis: 
The development of a general interprocedural framework that subsumes 
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Figure 1.3: Visualization of the organization of this thesis — including the relation 
to its title 


both data-flow analysis on control-flow graphs and context-sensitive slicing 
on program dependence graphs. 

In chapter 5, which directly builds on the first part of chapter 3, I derive a 
graph model that subsumes both control-flow graphs and program de- 
pendence graphs and, based on this model, a general data-flow framework. 
In addition, I discuss a variety of example analyses that can be expressed 
within this framework. 

Chapter 6 is concerned with the characterization of solutions to the prob- 
lems posed by instances of the data-flow framework in chapter 5. To 
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accomplish this task, I employ monotone constraint systems. I demon- 
strate that both the functional approach and the call-string approach can be 
applied to my general data-flow framework and that - under appropriate 
assumptions — both solve the problem with maximal precision. Because the 
unrestricted call-string approach in general does not allow a practical solu- 
tion algorithm, I also consider a technique that enables practical algorithms 
and maintains correctness (while sacrificing precision). In particular, this 
technique generalizes the well-known technique that was proposed for 
interprocedural data-flow analysis on control-flow graphs. 

In chapter 7, I describe algorithms for solving the constraint systems given 
in chapter 6. These algorithms combine a general worklist-based approach 
with a reachability analysis. For the functional approach, the algorithms 
that I obtain look like generalized versions of the well-known algorithms 
for context-sensitive slicing. 

In chapter 8, I present an implementation of the algorithms derived in 
chapter 7, describe an evaluation of the implementation and discuss the 
evaluation results. 

Chapter 9 gives a critical discussion of the work developed in the preceding 
chapters and relates it to the existing literature. 

Finally, in chapter 10, I recapitulate the contents of this thesis and give an 
outlook on possible future work. 


Usage of Personal Pronouns At this point, I want to briefly make clear 
the convention that I apply concerning the usage of personal pronouns in 
this dissertation. 

Generally, it is similar to earlier dissertations [39]: I will mainly use the 
first person singular. In proofs, I use the plural form in order to invite 
the reader to conduct them with me. An exception is chapter 4, where I 
report about research that was conducted by multiple persons, including 
me. This is why I use the plural form “we” there. Generally, I choose to 
deviate from these rules whenever I think that it is necessary. 
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Foundations 


2.1 Sets and Relations 


I assume in the following that the reader is familiar with basic set theory. 
This section is supposed to clarify the notations and conventions that I 
apply in this thesis. 


d 
For a given set A, I write 24 a {B | B C A} for the power set of A. 
8 p 


d 
For two sets A and B, A x B ar (a,b) |a € A Ab € B} is the cartesian product 


of A and B. Elements (a,b) € A x B are also called pairs. For the purposes 
of this thesis, I consider cartesian products associative, that is I identify 
A x (B x C) with (A x B) xC. Hence, the parentheses can generally be 
omitted. 

The cartesian product can also be considered for n € N sets A4,..., An: 


n 
d 
Axx An = [Ai = (aran) [VES i< n.a; € Ail 
i=] 


Elements (a1,...,an) of [];"_, Aj are called n-tuples. A special case is n = 0: 
TI; Ai is defined to be the set that consists only of the empty tuple {()}. 
In the following, I want to consider the special case of relations between 
two sets that I also call binary relations. 

A binary relation R C A x B is called 


1. left-unique if 


Vx Ee Ax’ eAVy € B.(x,y) ERA (x,y) ER —=x=x 
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2. right-unique if 
YxeAVy E€ BYy' E€ B.(x, y) ERA (xy) ER = y=y’ 


3. left-total if 
Yx € Ady € B.(x,y) E R 


4. right-total if 
Vy € B.Jx € A.(x,y) E R 


The domain of a binary relation R is 


dom(R) ČÍ {a € A | 3b € B. (a,b) € R} 


The image of a binary relation R is 


im(R) “! {b € B | 3a € A. (a,b) € R} 
If R is right-unique and a € dom(R), then I write R(a) for the one and only 
b € B such that (a,b) € R. Analogously, if R is left-unique and b € dom(R), 
then I write R71 (b) for the one and only a € A such that (a,b) € R. 
If RC A x B is right-unique, then R is also called partial function from A to 
B. For the set of partial functions from A to B, I use the notation A >p B. 
For f € A >p B, IL also write f : A >p B. If R is additionally left-total, then 
R is also called function from A to B. By A > B, I mean the set of functions 
from A to B and for f € A > B, I also write f : A > B. 
A function R is called 


1. injective if R is left-unique, 
2. surjective if R is right-total, and 
3. bijective if R is both injective and surjective. 


Every binary relation RC A x B can be assigned a function fr : A > 2, 
defined by 


fela) “! {b €B| (a,b) er). 


Occasionally, I will use Rand fr interchangeably, that is I will consider 
relations RC A x B as functions A > 2°. 
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2.2 Complete Lattices, Fixed Point Theory 
Theory and Monotone Constraint Systems 


In this section, I recall the basic notions that data-flow analysis builds 
upon and show generic algorithms that can be used to perform data-flow 
analyses. Particularly, I define monotone constraint systems and show 
how to solve them. 

In subsection 2.2.1, I recall and clarify the basic notions and compile import- 
ant results from the literature. In subsection 2.2.2, I introduce monotone 
constraint systems and characterize their solutions. In subsection 2.2.3, I 
present algorithms for solving monotone constraint systems. 


2.2.1 Partial Orders and Fixed-Points 


Partial Orders. A partial order is a tuple (L, <) which consists of a set 
Land a relation << L x L with the following properties: 


(reflexivity) Veel.x<sx 
(anti-symmetry) VxyelL.x<syAysx => x=y 
(transitivity) VxyzeL.x<yAy<sy => x<z 


Let (L, <) be a partial order and A C L. Then x is called minimal in A if 
Vy € A.x 2 y. Moreover, x € A is called least element of A if Yy € A. x < y. 
Note that least elements do not need to exist but are unique if they do, while 
minimal elements neither need to exist nor need to be unique. However, if 
A has a least element, then this element is necessarily minimal. Plus, if A 
is finite and non-empty, it always has minimal elements. 


Bounds. An element u € Lis called upper bound of A G Lif 
Vac A.a <u. 


Upper(A) denotes the set of upper bounds of A. u € L is called least upper 
bound of A if u is an upper bound of A and if 


Yu’ € Upper(A).u< w. 
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I also write |_| A for the least upper bound of A. l € L is called lower bound 
of A if 
VaeA.l<a. 


Lower(A), or | | A, respectively, denotes the set of lower bounds of A. l € L 
is called greatest lower bound of A if l is a lower bound of A and if 


YI’ € Lower(A).1’ <1. 


In the following, I compile some basic facts about least upper bounds 
and greatest lower bounds. Since they do not need to exist, I apply the 
usual convention for equations about partially defined objects: If I state 
an equation of the form x = y, I mean that either both x and y exist and 
coincide or that neither exists. 

Least upper bounds and greatest lower bounds are dual to each other in 
the following sense: 


(2.1) VACL.| |A=[ |upper(A) 
(2.2) VACL.| |A=| |Lower(A) 
Assume that A = {a,b} and that |_| A exists. Then we define 
d 
(2.3) a, Ua? = | Jaan 
d 
24) m na Zara) 


This defines partial binary operations LU, : L x L —y L. Easy calculations 
show that both Li and M are associative and commutative, that is 


(2.5) Va,beL.aub=buananb=bna 
(2.6) Va,b,ceL.au(buc)= (aub)UcAan(bNe) = (anb)Nne. 


These properties of U and M justify to extend both operations to arbitrary 
finite sets: 


(2.7) au = | flat, ..-an) 


(2.8) ayT---May 2 {ay,...,an} 


14 


2.2 Complete Lattices, Fixed Point Theory Theory and Monotone Constraint Systems 


Monotone Functions. For two partial orders (L, <) and (L, <’), I call 
a function f : L > L’ monotone, if 


(2.9) Y,belhsh => f(h)< f(b) 


Given a partial order (L, <) and a monotone function f : L > L, we can 
consider elements of L that behave specially with respect to f. I call x € L 


1. reductive if f(x) <x 
2. extensive if x < f(x) 
3. fixed-point if x is both reductive and extensive. 


The sets of reductive elements, extensive elements and fixed-points are 
denoted by Ext(f), Red(f) and Fix(f), respectively. 

If Fix(f) has a least element, i.e. if there is x € Fix(f) with the property 
Vy € Fix(f). x < y, then I call x least fixed-point of f and write it as Ifp(f). 


Complete Lattices. A complete lattice is a partial order (L, <) in which 
every subset has a least upper bound. In particular, it has a least element 


d d 
L =] | 10 = [Land a greatest element T ie oe. 


Theorem 2.1 (Knaster-Tarski, cf.[161, Theorem 1]). Let f : L > L bea 
monotone function on a complete lattice (L,<). Then Fix(f) is not empty and 
(Fix(f),<) is a complete lattice. In particular, we have 


| Ir) =| ag 


and 


| ]Fix(f) =[ | Red(f) 


Theorem 2.1 reduces the problem of finding the least reductive point 
to the problem of finding the least fixed point. Unfortunately, it is not 
constructive, in the sense that it gives no recipe of how to find the least 
fixed point. However, with some modifications, a constructive result can 
be given in the form of such a recipe. Before I present this result, I introduce 
some auxiliary definitions. 
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Chains and Chain conditions. A chain in (L, <) is a subset C C L 
such that 
Yx,yeCxsyVvy<x. 


With Chains(L) I denote the set of chains in L. A sequence (]j) jen is called 
ascending chain if 

VYı,jeN.i<j = li < lj 
I denote the ascending chains of L with Asc(L). A sequence (Ij) jen is called 
descending chain if 

VijENisj = ]2l; 
I denote the descending chains of L with Desc(L). 
It is important to consider the different natures of chains on the one side 
and ascending and descending chains on the other side. Any ascending 
or descending chain can be assigned a chain as follows: Every sequence 
can be considered a function / : IN —> L. Hence, we can consider the image 
im(l) of l and observe that im(I) is a chain if l is an ascending or descending 
chain. 
Conversely, for a given chain C, any monotone function 


1: (IN, <n) >L 


with C = im(L) can justify to regard C as ascending chain and any 
monotone function / : (N, >n) > L with C = im(L) can justify to regard 
C as descending chain. 

However, there are chains which cannot be considered as ascending or 
descending chains. Take for example the set Z of integers with its natural 
ordering and consider the set 2Z of even integers. It is easy to see that 
2Z forms a chain in Z but there is no monotone function !: N — Z with 
im(l) = 2Z (neither for <y nor for >y). 

A partial order satisfies the ascending chain condition, if every ascending 
chain eventually stabilizes: 


(ACC) Y(liJien € Asc(L)Ang € N. Yn > no. In = Ing 


A partial order satisfies the descending chain condition, if every descending 
chain eventually stabilizes: 


(DCC) V(l;)iem € Desc(L)Ang € N. Yn > no. In = Ing 
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If C is a finite chain, then the cardinality |C| is also called the height of C. 
Lis said to have finite height if there is n € IN such that every chain has a 
height of at most n. The smallest such n (if it exists) is also called the height 
of L and is written as height(L). 

Lis said to have no infinite chains, if all chains C C L are finite. 

There is a subtle difference between partial orders of finite height and 
partial orders with no infinite chains. Figure 2.1b illustrates the difference. 


no 
infinite 

ACC/ chains \DCC 
i, 


(a) 


Figure 2.1: (a): Relationship between different chain conditions - (b): proof sketch 
for why the inclusion between “finite height” and “no infinite chains” 
is proper 


As I elaborated on above, ascending and descending chains are special 
cases of chains. However, with regard to the respective chain conditions, 
there is a strong connection. 


Theorem 2.2 ([50, p. 2.40]). A partial order has no infinite chains if and only if 
it satisfies both the ascending and the descending chain condition. 


Chain-Complete Partial Orders. A chain-complete partial order (CCPO) 
is a partial order in which every chain in L has a least upper bound. In 
particular, a CCPO has a bottom element L = | | Ø, since 0 is a chain. 

Let (L, <) and (L’, <’) be two CCPOs. Then f : L > L’ is called continuous, 
if f is monotone and for every chain C in L we have f(LIC) = || f(C). 
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Theorem 2.3 (Fixed-point theorem of Kleene). If (L,<) is a CCPO and 
f :L— Lis continuous, then f has a least fixed-point that is characterized as 
follows: 


Ife(f) =| | F(a) 


ieN 
Proof. See, e.g., [28, Theorem 6.3.2]. oO 


Theorem 2.3 not only gives a constructive characterization of the least 
fixed-point, it also enables a powerful proof technique that I will make use 
of later. This proof technique is formalized in the following lemma (cf.[28, 
Theorem 6.3.5]). 


Lemma 2.4 (fixed-point induction principle). Consider a continuous function 
f:L—LonaCCPOL. Furthermore, let A G L be a subset of L which has the 
following closure properties: 


1. 1EeA 
2. YB € Chains(L).BCA = > ||BeA 
3. VaeL.acA — fla)eA 
Then Ifp(f) € A. 
Proof. Due to the assumptions about L and f, we can apply Theorem 2.3 
and obtain 

lfp(f) = || Fi) 

ieN 

With the help of properties 1 and 3 we can show by complete induction on 
ieN: 

ViEN. f(1)EA 
Finally, by property 2, we get 

fp) =| |F <A 


ieN 
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Every complete lattice is a CCPO. However, the fixed-point theorem of 
Kleene is not applicable under the assumptions of Theorem 2.1. For general 
complete lattices, not all monotone functions are continuous. However, if 
we restrict the lattice, monotonicity and continuity coincide and Kleene’s 
fixed-point theorem becomes applicable. 


Lemma 2.5. If (L, <) is a CCPO which satisfies (ACC), then every monotone 
function f : L > Lis continuous. 


Proof. Let f : L > L be monotone and assume that C G L is a chain. We 


must show that 
AMLUOFSLTEO 
Due to the monotonicity of f, it is clear that _| f(C) < f(LIC), so it suffices 


to show 
ALIO <| |©) 


This is easy to see if C is finite, so we assume that C is infinite. First we 
observe that |_| C € C, otherwise we could construct an ascending sequence 
(ci)ien With Vi € N. c; € Cand Vi, je N.i < j = ci < cjin contradiction 
to L satisfying (ACC). 

But |] C € C implies f (|_| C) € f(C) and this implies f(|] C) <LJf(C). o 


Corollary 2.6. If (L, <) is a CCPO which satisfies (ACC) and f : L > L is 
monotone, then the least fixed-point of f is characterized as follows: 


(2.10) ifp(f) =| | Fy) 


ieN 
In particular, there is ann € N such that Ifp(f) coincides with f" (1): 
(2.11) lfp) =f") 
Proof. By Lemma 2.5, any monotone function on L is continuous. Hence, 


the first claim follows by Theorem 2.3. 
Next, we show (2.11). For this, consider the set 


Ke If) lie NI 
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If Kẹ is finite, we choose n as the greatest number such that f"(-L) € Ky. 
This is always possible because Kẹ is not empty. For this choice of n, (2.10) 
implies (2.11). 

Now consider the case that Kẹ infinite. We take a look at the observation 
made in the proof of Lemma 2.5: It said that | | C € C for every chain C C L, 
provided that L satisfies (ACC). Plus, an easy inductive argument shows 
that K f is indeed a chain. Hence, we may conclude that 


| Kr € Kr. 
In other words, there must be n € N such that 
EIE a 
ieN 
as desired. oO 


Corollary 2.7. Let L be a CCPO which satisfies (ACC) and f : L > L bea 
monotone function on L. Furthermore, let A C L be a subset of L which has the 
following closure properties: 


1. LEA 

2. YB € Chains(L). BCA = > ||BeA 

3. VaeL.acA — fla)eA 

Then Ifp(f) € A. 

Proof. This follows from Lemma 2.5 and Lemma 2.4. m 


The ascending chain condition also comes in handy when we want to 
show that a partial order is a complete lattice. With (ACC) it is enough to 
show the existence of a bottom element and that every finite subset has a 
least upper bound. This is formalized by Lemma 2.8. 


Lemma2.8. Let (L, <) be a partial order that satisfies (ACC). Then the following 
statements are equivalent: 


1. Lis a complete lattice. 


2. Lhas a least element L and for every x, y E L, x U y exists. 


Proof. This follows from [50, p. 2.41]. m| 
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Some Constructions I want to conclude this section with the com- 
pilation of some examples of complete lattices, which will play a role later 
in this thesis. 

For any set A, the power set 2“ with respect to set inclusion forms a 
complete lattice (24, C), called the power set lattice of A. If A is finite, then 
the power set lattice of A has finite height. If A is infinite, then neither 
(ACC) nor (DCC) are satisfied. 

If (Ly, <1) and (Ly, <2) are two partial orders, then the cartesian product 
(L1 x L2, <) forms a partial order where < is the relation 


d 
way) EE xe ayscy’ 


Moreover, 
e (L4 x L2, <) is a complete lattice if both L4 and L} are. 
e (L4 x Lz, <) satisfies (ACC) if and only if both L4 and La do. 


This can be generalized to an arbitrary finite number of complete lattices. 
If (L, <) is a partial order and A is any set, then the set of total functions 
A > Lisa partial order with 


fzg &b wee. f(x) < g(x) 


If L is a complete lattice, then A — L is, too. Moreover, if L satisfies (ACC) 
and A is finite, then A > L satisfies (ACC). Conversely, if A — L satisfies 
(ACC), then either L contains only one element or A is finite and L satisfies 
(ACC). 

If (Ly, <1) and (Lz, <2) are partial orders, then the space Lı mon L2 of 
monotone functions is a partial order via the relation defined above. Plus, 
if Ly is a complete lattice, then L4 mon Lz is also a complete lattice. That 


is, for any set A G L4 mon L2 of monotone functions, the least upper 
bound defined by 


(Aw =| Iroıre A 


is also monotone. 
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2.2.2 Monotone Constraint Systems 


In this section, I introduce monotone constraint systems. These systems are 
fundamental for program analysis and in particular for data-flow analysis, 
since they are expressive enough to describe abstractly how a program 
propagates values. 


2.2.2.1 Syntax 


I start with a set X of variables and a set F of function symbols. Every 
function symbol has an arity a(f) € IN. Particularly, I allow function 
symbols with a( f) = 0, which I also call constants. 

The set Expr(X, F ) of expressions over X and F is defined inductively as 
follows: 


1. X C Expr(X,F) 


2. f f eF witha(f) =nandtı,...,tn € Expr(X,F ), then f(tı,...,tn) € 
Expr(X,F ). 


A monotone constraint (or constraint for short) has the form x > t where x is 
a variable and t € Expr(X,F ) is some expression over X and F. 

A (monotone) constraint system is a set C of constraints. 

With FV (t) I denote the variables occurring in t € Expr(X,f ). I refer to 
FV(t) as the set of free variables in t. 

Let C be a monotone constraint system and c = x>t € C. Then I define 


d d 
ths(c) Z x and rhs(c) = t and refer to Ihs(c) and rhs(c) as the left-hand 
side and right-hand side of c, respectively. 
With Vars(C), I denote the set of left-hand sides of constraints in C, i.e. 


(2.12) Vars(C) = {Ihs(c) |c € C} 


For a constraint c € C with x = Ihs(c), I also say that c defines x and refer to 
c as defining constraint for x. 


Definition 2.9. Let C be a constraint system. 


1. Idefine» C CXC by x >to x >t ifx € FV(t’). With ~* I denote the 
reflexive-transitive closure of > and with ~»* the transitive closure. 
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2. For sets C1, Ca CC of constraints I write C4 > C2 if 
Ic & Cj. Ac = Co. C1 ~ C 


Cy ~œ* Ca and Cy ~>* Cz have the respective meaning. Instead of {c} ~> C2, I 
also write c ~> Cz (analogously for Cz = {c}). For Co < C I denote with C$ the 


set {c E€ C : Co ~* c} (Cy is defined analogously). 


3. For x € X I denote with Def (x) the set of constraints with x on the left-hand 
side. 


4. I overload ~ to ~C X x X as follows 
xx — Def (x) ~ Def (x’). 


~*C XxX and ~»*C X x X have the respective meaning for sets of variables. 


2.2.2.2 Semantics 


In the following, I define what it means for a constraint system to be 
satisfied. In a nutshell, I assign every occurring expression a monotone 
function on an appropriately chosen partially ordered set L. This allows 
to evaluate the left-hand side and the right-hand side of a constraint and 
to determine whether the left-hand side is greater than or equal to the 
right-hand side, with respect to the partial order on L. 

Let (L, <) be a partially ordered set. 

A variable assignment is a function i : X > L. Furthermore, I assign every 
function symbol f € F with a(f) = n a monotone interpretation a(f) : 
L” non L. Now I inductively define the interpretation [t] : (X —> L) > L 
of expressions: 


e forxe X: [xI(y) = y) 
© Dr. tI) = aA), -o Ln) 


By straight-forward induction I can show Lemma 2.10, which states basic 
but important properties of [-] and FV. 


Lemma 2.10. Let t € Expr(X,¥ ) be an expression. Then the following state- 
ments hold: 
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1. [t] : (X > L) > Lis monotone. 


2. If and y” are two variable assignments with 


Yx € FV(t). p(x) < y’ (x), 

then 
L) < I’). 

In particular: Vx € FV (t). y(x) = y’ (x) implies [t] (4y) = IEI). 
A variable assignment y : X > L satisfies a constraint x > tif W(x) > [t] (y). 
y satisfies a constraint system if it satisfies all c € C. I this case, I call ya 
solution of C. y is called least solution of C if Y < y” for all solutions ı of C. 
Given a constraint system C I define the corresponding functional 

Fe: (X >L) > (X >L) 


by 
Fe(p)(x) =| Hkt eC} 


For the moment, I implicitly require that Fç is well-defined, i.e. that all 
least upper bounds on the right-hand side exist. 

An easy calculation shows that Fç is monotone. Furthermore, there is a 
strong connection between the solutions of C and the reductive points of 
Fe: 


Lemma 2.11. y is a solution of C if and only if Fo(w) < y. 


Proof. “ ==”: Assume Fo(w) < w and let x>t € C. Then, by definition of 
Fe, 
Fe()(x) 2 A) 
Since Fe(w) < y, this implies 
v(x) > TAY) 


Hence, y is a solution of C. 
“=>”: Tf we have y(x) > [t] (y) for every x>t € C, then 


Wx e X.p(x) >| HE2 EC} = Fely) a) 
which is equivalent to y > Fe(w). m) 
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The connection between the solutions of C and the reductive points of Fe 
makes the theory developed in section 2.2 available. The least solution 
exists and coincides with the least fixed-point of Fç if 


e Lisa CCPO and Fç is well-defined and continuous, or 


e Lis a complete lattice. 


If Lisa CCPO and Fç is well-defined and continuous (which is for example 
the case if L is a complete lattice satisfying the ascending chain condition), 
then the least solution is characterized by 


Ifp(Fo) = |_| Fo(4). 


ieN 


2.2.3 Solving Monotone Constraint Systems 


Now we know how monotone constraint systems look like and what they 
mean. In the following, I show algorithms that can solve them under some 
common conditions. 

Let C be a monotone constraint system over a complete lattice L that 
satisfies the ascending chain condition. Then Kleene’s fixed-point theorem 
(Corollary 2.7) suggests a simple algorithm to compute the least solution 
of C, which is presented in Algorithm 1. 

Algorithm 1 is indeed very simple. From previous considerations, it can 
easily be seen that Algorithm 1 must terminate and that upon termination, 
the value of A is indeed the least fixed-point of Fç and therefore the 
least solution of C. On the other hand, it is very inefficient: Fo(A) is 
computed by computing Fe(A(x)) for all x € X and Fe(A) (x) is computed 
by evaluating [t] (A) for all t such that x > t € C and computing their 
supremum. In effect, all constraints are evaluated and this is re-iterated 
for all constraints, even if only one value changed. 

More efficient algorithms can be obtained by carefully tracking the con- 
straints that need to be updated. For every constraint x > t, according 
to Lemma 2.10, [t] only depends on FV(t), i.e. it can only change if the 
value of at least one y € FV(t) has changed. Conversely, this means: If we 
re-evaluate A(x) and it changes, then afterwards we only have to consider 
those constraints where x occurs on the right-hand side, i.e. the constraints 
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Algorithm 1: Simple algorithm to compute the least solution of a 
monotone constraint system 


Input: a finite monotone constraint system C 
Result: the least solution of C 
A-L 
changed — true 
while changed do 

changed — false 

Aod — A 

A — Fo(A) 

if A # Asq then 

| changed < true 


o N OAU Ff WN m 


wo 


return A 


of the form y > t such that x € FV(t), or, in the spirit of Definition 2.9, 
which are related to x > t via C’s ~»-relation. 

We now can give an improved version of Algorithm 1, which is shown 
in Algorithm 2. This algorithm does not apply Fe globally but considers 
each constraint individually. 

Like Algorithm 1, Algorithm 2 maintains a function A : X — L which is 
initialized to L for all x and then updated incrementally. Additionally, 
it maintains a list of constraints which have to be considered later - the 
so-called worklist?. This list initially contains all constraints, which ensures 
that every constraint is considered at least once. In the iteration phase, 
the worklist is processed as follows: First, a constraint x > t is removed. 
Then, the algorithm checks whether the current value of A satisfies this 
constraint. If this is the case, the constraint can be discarded and A is left 
unchanged. If this is not the case, then A is updated. After the update, A 
satisfies x > t. Lastly, all constraints which may be influenced by x, i.e. all 
x’ >t’ such that x ~ x’, are inserted into the worklist. This ensures that 
every constraint that may have been violated by the recent update of A 
will be considered again later. 


3] use the term worklist here although the algorithms treat W like a set. The reason is 
that I do not want to deviate from the literature too much. 
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Algorithm 2: Worklist algorithm for computing the least solution 
of a monotone constraint system (adapted from [130, Table 6.1]) 


Input: a finite monotone constraint system C 
Result: the least solution of C 

ıW-9 

2 foreach x>t € C do 

3 W«-Wulx>t 

4 | A(x) L 

5 while W + Ø do 

6 | x>t<remove(W) 

7 | new <— eval(t,A) 

8 | if A(x) ž new then 

9 A(x) — A(x) Unew 

10 foreach x’ > t such that x > t~ x’ >t’ do 

11 | wewußtzt) 


12 return A 


By considering each constraint at least once and ensuring that a constraint 
is considered again if the value of an influencing variable has changed, it 
can be shown that Algorithm 2 indeed computes the least solution of C, as 
stated by Theorem 2.12. 


Theorem 2.12 (cf. Lemma 6.4 in [130]). If C is finite and L satisfies the 
ascending chain condition, then Algorithm 2 computes the least solution of C. 


Note that Algorithm 2 does not specify how elements are inserted into 
the worklist and how they are removed. This means that the algorithm is 
correct no matter in which order the constraints are processed, so that it 
can be further improved by optimizing the evaluation order. 

Instead of maintaining constraints in a worklist, one can also maintain 
variables instead of constraint. This leads to Algorithm 3. Here, the 
worklist contains all the variables whose value needs to be updated. 


Theorem 2.13. IfC is finite and L satisfies the ascending chain condition, then 
Algorithm 3 computes the least solution of C. 


Proof. We prove the claim as in the proof of [130, Lemma 6.4] in three steps: 
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Algorithm 3: A variable-oriented variant of Algorithm 2 


Input: a finite monotone constraint system C 
Result: the least solution of C 

1 foreach x>t € C do 

2 | A(x) L 

3 W e WU {x} 

4 while W #0 do 

5 | x remove(W) 

6 | old — A(x) 

7 | forallx>teCdo 

8 A(x) — A(x) UE (A) 

9 if A(x) # old then 

10 foreach x’ > t’ € C such that x € FV(t’) do 
| | W-Wuh’!} 


12 return A 


1. Algorithm 3 terminates. 


2. If A; denotes the value of A after the i-th iteration, then 


Vie N. A; <1fp(Fc) 
3. Upon termination, we have 
A21fp(Fc) 


For the first two steps, we refer to the proof of [130, Lemma 6.4]. For the 
third step, we prove that the loop in lines 4-11 maintains the following 
invariant: 


(Inv) Vx=teC.x€W = > A(x) = HIA) 


First we note that this invariant proves our claim: Upon termination, the 
worklist is empty. The invariant (Inv) implies then that every constraint is 
satisfied. 

Next we show that (Inv) holds before the first loop iteration. But this 
is clear since after the initialization loop in lines 1-3 has finished, every 
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variable occurring on the left-hand side of a constraint in C is contained in 
W. Hence, the premise of (Inv) is false, so (Inv) holds before the first loop 
iteration. 

Next we show that (Inv) is preserved by each iteration of the loop in lines 
4-11. So, consider the i-th loop iteration. Let Aoig and Wojq be the values 
of A and W at the beginning and Anew and Wyew be the values of A and 
W at the end of the i-th iteration, respectively. We assume that (Inv) holds 
at the beginning of the i-th iteration and show that it still holds at the end. 
So, consider any constraint x>t € C with x € Wnew- 

We distinguish two cases: 


1. x & Wo: Then x > t was satisfied at the beginning of the i-th loop 
iteration and x cannot have been removed in this iteration, which means 
that A(x) is not touched. Moreover, no variable from FV (t) can have been 
touched in this iteration: Otherwise, line 11 would have been executed 
and x € Wyew. Hence, x > t is still satisfied at the end of the iteration. 


2. x € Woga: Since x € Wyew, x must be the variable which is processed 
in the i-th iteration. Then, at some point, line 8 is executed for x > t, so 
that x > t is satisfied afterwards. Now we make three observations that 
together allow us to conclude that x > t is still satisfied at the end of the 
ith iteration: First, we see that line 8 is the only place in the loop where 
A(x) is modified. Secondly, A is only modified for variable x and no other 
variable. Finally, we make the observation that no variable from FV(t) can 
have been touched in this iteration: If that were the case, then this would 
necessarily entail x € FV (t). But then line 11 would be executed for x > t 
and we would have x € Wyew (which we have not). 


From these three observations, it follows that the i-th iteration only changes 
Analysis(x) and leaves [t] (Analysis) unchanged. Together with the fact 
that line 8 changes Analysis(x) upwards, we can conclude that x > t is still 
satisfied at the end of the i-th iteration. 


This concludes the proof that (Inv) is preserved by the loop in lines 4-11. 
oO 
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2.3 Inductive Definitions 


In later chapters, I will use inductive definitions at various places. Further- 
more, I will use induction principles derived from the respective definition. 
In this section, I make these notions precise by applying the theoretic 
foundations compiled in section 2.2. A general version of the following 
definitions and results can be found in the literature [7]. 

To improve presentation, I abbreviate (x1,...,Xn) € B” as x € B”, fora 
given set Band n € IN. Moreover, for x € B", I write x; to denote the i-th 
component of x. 


Definition 2.14. Let X be an arbitrary set. An operator (on X) is a partial 
function f : X" — X for some n € N, which is also called the arity of f and 
which is written as ar(f). 


Definition 2.15. For a set F of operators (ona set X), I say that A G X is closed 
under F if 


(2.13) VE EF. Wx e XM). xe AMS) Ndom(f) = fx) <A 


Usually, I will specify F by giving a list of closure properties of the form 
(2.13). 
Mostly for layout reasons, I express (2.13) in the following way: 


EA. KA xedom(f) 
FW eA 


Occasionally, I will omit the “€ A”’s if they are clear from the context. I 
will also omit other assertions that restrict elements to membership in a 
given set if these assertions do not restrict the elements more than other 
assertions. I will also omit quantifiers and assume that all free variables 
are universally quantified. 

Using (2.13) or (2.14) not only specifies an operator set on X but also a 
canonical subset of X. I introduce this set in the following. 


Definition 2.16. Let F be a set of operators on the set X. I say that A C X is 
inductively defined by F if 


(2.15) A is closed under F 
(2.16) VB C X. Bis closed under F — ACB 


(2.14) 
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Remark 2.17. For every set X and every set F of operators on X, there is exactly 
one subset A C X that is inductively defined by F. 


Proof. Define A by 


(2.17) A pat Ri: C X | Bis closed under F} 


Then it can be easily seen that A satisfies the two conditions in Defin- 
ition 2.16. Now let Ay < X and Ag € X be two subsets of X that are 
inductively defined by F. Then by (2.15), both A; and A3 are closed under 
F. Hence, by (2.16), we have A; C An and A? < A4. Due to anti-symmetry 
of G, it follows that A; = An. Oo 


Because of (2.16), one can also say that the set that is inductively defined 
by F is the least subset that is closed under F 

For an inductively defined set A < X, the following proof principle can be 
applied. 


Theorem 2.18. Let A C X be inductively defined by F and let P : X > 
{true, false} be a statement about elements of X. Suppose that we can show 


ar(f) 
(2.18) vfeF.Vxe x"), xedom(f) a A Pix) = PEK). 
i=1 


Then Va € A. P(a). 
Proof. Define C4,Cz : 2% > 2% by 


(2.19) CB) = tf (x) [x € Be) Adom(f)} 


(2.20) cr (B) = |J c8) 
fr 


Then it is easy to see that 
1. Cy is a monotone function on the complete lattice (2%, c). 


2. The subsets of X that are closed under F are exactly the reductive points 
of Cr: 
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From Theorem 2.1, we know that 


Ifp(C¢) = ( |Red(Cz) 
Hence, l fp(C¢-) is the least subset of X that is closed under F. 
Another basic observation is that for all A C 2X we have 


crl JA) = |) cra) 


ACEA 


In particular, Cz is a continuous function on the CCPO 2%. Hence, we can 
use Lemma 2.4 to give a proof for Theorem 2.18. Abbreviate Ifp(Cz) as A 
and define 


PÍ BcA |Ybe B. P(b).} 

Then we need to show A € P. By Lemma 2.4, it suffices to show 
(2.21) PEP 

(2.22) VB CX. BCP => | |BeP 

(2.23) VBCX.BEP = Ce¢(B) EP 


The first two properties are easy to see. Now consider (2.23). Let B € P. 
We need to show C¢(B) € P, that is 


LJ Ff) Ix EB” ndom(f)} eP 
JEF 


By (2.22), it suffices to show that 
(f(x) Ixe BY) Ndom(f)} EP 


for all f € F. For this, it is sufficient to show 
yf € F. Yx € BY) n dom(f). P(f(x)) 


So let f € F and x € B"(f) n dom( f). From B € P we can derive 
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and by (2.18), ea 
x)) €B, 


follows, as desired. oO 


In this thesis, I will at several points consider a set A that is defined in some 
non-inductive way. Then, I will specify a set F of operators and propose 
that A is inductively defined by F. In order to show this, by Remark 2.17, 
I only need to show that A is the least set that is closed under F. The 
following theorem formalizes this argument. 


Theorem 2.19. Let X beaset, F aset of operators on Xand A C X. Furthermore, 
let Xo < X be the least subset of X that is closed under F. In order to show that 
A is inductively defined by F, it suffices to show the following two statements. 


(2.24) A is closed under F. 
(2.25) A C Xo, where Xg is the least subset of X that is closed under F. 


Proof. (2.24) is exactly the same as (2.15). (2.25) is a reformulation of 
(2.16) with regards to the representation (2.17). Hence, (2.24) and (2.25) 
indeed imply together that A is inductively defined by F according to 
Definition 2.16. Oo 


2.4 Symbol Sequences 


Let E be a finite set. I will refer to E as alphabet and to the elements of E as 
letters, or symbols, respectively. 


is the set of sequences with items in E and length n. In particular, E? 
contains exactly one element e that I also call the empty sequence. 


E* je 


i20 


is the set of all sequences with items in E. 
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I will use some abbreviating notations: I will use an interval notation 
for ranges of integers. For instance |i, j| < N is meant to be the set of 
non-negative integers which are > i and < j, the notation for open and 
half open intervals ji, j[, [i, j| and ]i, j| have respective meaning. For a 
sequence n € E* of symbols from E, 7! and |n| denote the i-th item in 7 
and the length of n, respectively. Moreover, I define nii, nbi [| mt] and 
rtil as the sub-sequence of 7 that is obtained by taking only the items 
of the respective intervals. So, for example, if m = n....-7"-1, then 
0.il, > is short for nlrl-1], a$$ and 


nlii = Tr. Th. n“Í is short for n 
nm! are defined analogously. Generally, I consider 7’ a sub-sequence of 7 
if and only if n’ = n! for some interval I C range(rt). Moreover, although 
I will mostly treat 77! as a sequence of its own right, I consider it to also 
implicitly contain the interval I and the sequence 7 from which it was 
extracted. This avoids ambiguities for cases in which there are multiple 
occurrences of a sub-sequence in a sequence. For instance, for n = abab, 
the sub-sequence ab could be represented as both nA and nls, By also 
incorporating the interval, I specify which occurrence of ab I mean. 

Both x and I will be clear from the context, unless stated otherwise. 

For a sub-sequence n’ = nl of n, I denote with rangen (n) := I the range 
of indices which need to be selected from 7 to obtain n’. If I omit the index, 
then I mean the full range of 7, so range(n) = {0,...|77| — 1}. 

Lastly, Prefixes(r) := {n“ | i € range(z)} is the set of all prefixes of 7. 


def 3 
Sequences can be concatenated. For n € E”, n’ € E", n” = n:n is the 


sequence of length m + n with n” < = n and n”>"l = 7’. This defines a 
binary operation on E * i.e. a function 


.: E* x E* > E*. 


This operation is associative, that is (744 - T2) - T3 = T4 : (a: 713) and has e 
as neutral element, that is we have n-e=e-n = n. Moreover, for every 
m € E*, if we split range(7) into adjacent intervals Iı,..., Ip that only have 
endpoints in common, then we can write 
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Specifically, by considering each symbol in a sequence rı as a sequence of 
its own right, then we can write 


n=n®.,....el-1 


2.5 Directed Graphs 


The following definitions are standard and can be found in any text book 
about graph theory [44, 55]. 


Definition 2.20. A directed graph is a pair G = (N, E) where N is a set of 
nodes and EC N xN is a binary relation over N whose elements are called 
edges. 


Definition 2.21 (edge labels). An edge-labeled directed graph is a tuple G = 
(N,E,L,1) such that (N, E) is a directed graph and 


l:E>L 


is a function from edges to a finite, non-empty set L of labels. I assume that L 
always contains the empty label t. 


For e € E, I will write n > n’ if e = (n,n’) or, for labeled edges, if 
Jl.(n, 1, n’) € E. Given a (labeled) edge n  n’, src(e) = n and tgt(e) = n’ 
denote the source and target of e, respectively. 

For a given sequence n € E*, n + e, I define start and end as follows: 


(2.26) start(r) = src(n°) 
(2.27) end(r) = tgt(n'™-1) 
A path is an edge sequence n € E* with the property 


V1<i<|n|-1.sre(n‘) = tgt(n™!). 


We can characterize the paths in G as follows. 
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The set Pathsg C N x N x E* is inductively defined by the following rules: 


(PATH-EMPTY) ———— 
(s,s,e) € Pathsg 


(s,t,n)ePathg tt! 
(s,t’, T- e) € Pathsg 


(PATH-EXTEND) 


Instead of (s,t,n) € Pathsg, I also write z € Pathsg(s, t) and refer to Pathsg 


as function N x N > 2E*. 

It is easy to see that Pathsg relates the pairs (s,t) € N x N to the paths 
that start in s and end in t, as formalized in Lemma 2.22. Occasionally, I 
will consider Pathsg not only as a relation but also as a subset of E* by 
identifying it with Us ren {7 € E* | (s, t, 7) € Pathsg}. It will be clear from 
context, which of the two I mean. 


Lemma 2.22. For all n € E* and all s,t € N the following two statements are 
equivalent: 


(1) (s,t,7) € Pathsc 
(2) misapathand (s = t AT =eVstart(m) =sNend(n) = t) 


” 


Proof. “ => ” can be seen by induction on (s,t,7) € Pathsg, “ ==” can 
be shown by induction on the length of sequences in E*. m 


Lastly, I state three elementary properties of paths that I will make use of 
later. 


Lemma 2.23. If n € Pathsc(s,t) and n’ € Pathsc(t,t’), then n:n € 
Pathsc(s,t’). 


Proof. Fix s,t € N and n € Pathsg(s, t). Then we can show 
Yn’ € E*. Vt EN. n ePathsc(t,!) — n:n € Pathsc(s,t’) 
by induction on the length of 7’. m 


Lemma 2.24. For all n,n’ € E*, the following statement holds: 
If nn’ € Pathsc(s,t), then there ist! € N such that n € Pathsc(s,t’) and 
mt’ € Pathsc(t’,t). 
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Proof. Fix n’ € E* and t € N. Then we can show 


Yr € E*. Ys € N. n:n’ € Pathsc(s,t) 
=> dt’ e N.n e Pathsc(s,t’) An’ € Pathsc(t’, t) 


by induction on the length of 7. m! 
Remark 2.25. If n is a path and i, j € range(n), then nbl is a path. 


Proof. This is clear by definition. m 
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THE BEATLES 


Program Dependence Graphs 
for Object-Oriented Programs 


This chapter introduces the reader to common terminology and patterns 
of thought used in static program analysis. Moreover, it describes sev- 
eral techniques that enable Joana to analyze security properties of Java 
programs. This prepares the reader for chapter 4, which shows several 
applications of the information flow control tool Joana to software security. 
This chapter plays another important role: It describes two fundamental 
and widely used static program analysis techniques, namely data-flow 
analysis on control-flow graphs and slicing on program dependence graphs. 
These two techniques, which were developed more or less independently, 
face similar issues that have been solved with analogous approaches. In 
later chapters, I will present a common generalization of data-flow analysis 
and slicing that combines the strengths of both techniques. 

The following sections are structured as follows. In section 3.1, I give an 
overview of basic aspects of static program analysis and introduce several 
central concepts that play important roles throughout this chapter. After 
that, section 3.2 and section 3.3 present data-flow analysis on control-flow 
graphs and slicing on program dependence graphs, respectively. 

Finally, in section 3.4 I describe Joana and show how it can be used to 
verify non-interference for Java programs. In this last section, I put an 
emphasis on the explanation of several techniques that are particularly 
important for the analysis of the programming language features of Java 
and also play a role in chapter 4. 
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3.1 Principles of Static Program Analysis 


Program Analysis is concerned with techniques that allow to derive 
information about a given program and its properties. Roughly, program 
analysis techniques can be grouped into dynamic techniques and static 
techniques. Dynamic techniques generate information while executing the 
program [75], while static techniques aim to analyze a program without 
executing it [130, 76]. 

Another criterion that can be used to classify program analyses is whether 
they are automatic or not. As the name suggests, an automatic program 
analysis is usually another program that takes a given program as input, 
performs some algorithm on it and outputs its analysis result. In contrast, 
non-automatic techniques are either fully manual or interactive, that is they 
generally employ automatic techniques but query the user if they cannot 
complete their task in an automatic fashion. 

In this thesis, I focus on automatic and static program analysis techniques 
such as data-flow analysis [101] and static program slicing [165, 166, 58]. In 
the following, I assume that all analyses are static and automatic, unless 
explicitly stated otherwise. Furthermore, I assume that the programs 
under analysis are written in a Turing-complete language. 

Two important concepts in program analysis are soundness and precision’. 
Before I explain these two concepts, I first introduce some formalisms: Let 
@ be a property of programs, that is a given program Ff either can satisfy 
Q, written P = ọ, or not, written P |# p. The property & can for example 
make a statement about P’s semantics, i.e. about how P transforms states 
or can state that P is secure in some sense. 

Now let A be a program analysis whose goal is to analyze programs 
with respect to @. Formally, we can imagine A as a function that takes 
a program F as input and outputs either “P satisfies p” or “P does not 
satisfy @”. We write the former as P Ha ¢ and the latter as P ra $. 

Note that the result of A a priori has nothing to do with whether P actually 
satisfies @ or not. It is merely a consequence of the formal reasoning 
performed by A. 

The notions of soundness and precision establish a connection between + 
and + A: 


“In the area of formal systems, precision is also called completeness. 
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1. Ais said to be sound with respect to œ if 


Prap = Pb. 
That is, if A concludes that P satisfies &, then this is indeed the case. 


2. Ais said to be complete with respect to ¢ if 


That is, if P has property @, then A is able to derive that. 


If Ais sound, then it can give the guarantee that a program actually satisfies 
a property. If it is additionally complete, then it is actually able to decide &. 
Unfortunately, there can be no static automatic analysis for a non-trivial 
property of programs written in a Turing-complete programming language 
that is both sound and complete [142]. Hence, analysis designers must 
make compromises, i.e. analyses usually are usually not sound or not 
complete (or neither of the two). 

In the context of static program analysis, completeness is commonly 
also referred to as precision. Throughout this thesis, I use both terms 
interchangeably. 

It is common to focus on soundness and sacrifice precision, especially in 
security analyses where one aims to give strong guarantees for programs. 
However, if an analysis is not precise, then it may raise false alarms, e.g. 
report that a program is insecure although it is not. This can undermine 
the credibility of an analysis. 

Hence, another goal of program analysts is to minimize false alarms, i.e. 
make their analyses as precise as possible. Note that, although precision in 
theory is a binary property that can be either true or false, in this thesis I 
use it as a property that has multiple degrees, so that it can also be used 
comparatively or even quantified. Given two analyses A, and A», one 
can say that A, is at least as precise as Ap if 


(PIPE PAP Fa, PG} SIPIPE PAP EKA, >}. 


This defines a partial order on the set of analyses that can be used to 
compare different analyses. 

There are different trade-offs that can be made with respect to analysis 
precision. In the following, I give an overview of a selection of them 


41 


3 Program Dependence Graphs for Object-Oriented Programs 


int z = input(); int z = input(); 

xX = 2; xX = 2; 

if (z*z+2z+ 1 == 0) { if (z*z-9 == 0) { 
x = 3; x = 3; 

} } 


(a) (b) 


Figure 3.1: Example for the impact of value-sensitivity 


that play some role in this thesis. For illustration, I will use the example 
property upon program termination, variable x always has the value 2 that I 
write as yx. 

One trade-off static analyses can make is how precisely they handle values, 
for example numbers and algebraic identities. 

Consider the two programs in Figure 3.1. Since the quadratic function 
z? +z +1 does not have any integral zeros, it is relatively easy to see that x 
is always 2 upon termination of the program in Figure 3.1a, hence yx holds 
for it. However, yx is not satisfied by the program in Figure 3.1b, since x 
is set to 3 if z = 3. A program analysis that is sound with respect to yx 
but does not reason about algebraic identities will fail to verify yx for the 
program on the left. There are analysis techniques that can deal with such 
challenges[128], but the techniques that I consider in this thesis usually do 
not reason about values beyond the use of limited constant propagation 
[126]. 

Another aspect of analysis precision is flow-sensitivity, a property that refers 
to the ability of an analysis to take the order of statements into account. 
As an example, it is clearly the case that the program P in Figure 3.2a 
satisfies yx, while program P% in Figure 3.2b does not. Now consider an 
analysis A that is sound with respect to yy. Then it must be the case that 
P2 KA yx, because P2 E yx. Now, if A is flow-insensitive, then it usually 
yields the same result for P4, as they only differ in the order of statements. 
Hence, a flow-insensitive analysis is usually not able to verify yy for P4. 
In contrast, it may be the case that a flow-sensitive analysis may consider 
P1 and P3 as different programs. 

Context-sensitive program analyses consider not only the program state- 
ments, but also take their execution context into account. Examples for the 
execution context of a statement include the site from which a procedure 
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void main() { void main() { 
y = F(3); x = F(2); 
x = f(2); x = F(3); 
} } 
void f(int a) { void f(int a) { 
x = 3 xX = 2 return a; return a; 
x = 2 x = 3 } } 


(a) (b) (c) (d) 


Figure 3.2: Illustration of different sensitivities: Programs a and b cannot be 
distinguished by a flow-insensitive analysis, programs c and d cannot 
be distinguished by a context-insensitive analysis 


was called (in programs with multiple procedures), or the object on which 
a method is called (in object-oriented programs). 

For example, it clearly can be seen that the program in Figure 3.2c satisfies 
yx, while the program in Figure 3.2d does not. However, a context- 
insensitive program analysis that is sound with respect to yy cannot verify 
Figure 3.2c: It has to “merge” the calls in lines 2 and 3 and deem it possible 
that f may also return 3, otherwise it would not be able to reject the program 
in Figure 3.2d. 


3.2 Data-Flow Analysis on Control-Flow 
Graphs 


In this section, I introduce control-flow graphs, a classical data structure 
of static analysis and data-flow analysis, which is an important, generic 
operation on control-flow graphs that forms the essence of many static 
program analyses. 

This section is structured as follows: First, I introduce control-flow graphs 
in subsection 3.2.1. After that, I explain how data-flow analysis works in 
subsection 3.2.2. 

The two subsections are structured analogously: First, they consider 
programs without procedures and then show how the respective formalism 
can be extended to the interprocedural case. 
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entry 


Y 


1 read(n) 1: read(n) 

2 if (n<=1){ 4 

3 print(n) (2: n<=1 >G: a= 0) 

4 } else { pyes Y 

5 a= 0 43: print(n)) (6: b= 1) 

6 b= 1 

7 Era) 7: c=atb 

8 i=0 

9 while (i < n) { u 

10 Sa 8: i=® 

11 b=c Y es 

12 ea [15: print(c) }#2(9; i PR ae: a=b 
13 i=zi+l i j 


14 } 11: b=c 


15 print(c) 
16 } 12: c=at+b 


Y 
exit) 13: isi+1 


Figure 3.3: An example program and its control-flow graph 


3.2.1 Control-Flow Graphs 


Control-flow graphs are a classical program representation on which many 
program analyses operate. A control-flow graph of a given program P 
is a directed graph that represents the possible control-flow between P’s 
statements and predicates. 


3.2.1.1 Intraprocedural Control-Flow Graphs 


An example of a simple program and its control-flow graph can be seen in 
Figure 3.3. Its nodes represent the program’s statements and predicates. 
Directed edges connect nodes with those nodes which may immediately 
follow them in an execution. 

There are two kinds of control-flow. The control-flow from line 1 to line 2 
is unconditional: After the read operation has been executed, control is 
always transferred to the following if statement. 
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The control-flow from line 2 to line 5, however, is conditional. Line 5 is 
only executed if the predicate in line 2 is evaluated to true. If it is evaluated 
to false, line 3 is executed instead. 

It is also a common assumption that control-flow graphs have a unique 
entry node from which all nodes in the control-flow graph are reachable 
and a unique exit node which can be reached by all nodes. 

Next, I introduce control-flow graphs more formally. 


Definition 3.1 (control-flow graph, [65, based on Definition 2.1]). Given 
a procedure (or procedure-less program) P, a control-flow graph (CFG) is an 
edge-labeled directed graph with two distinguished nodes s,e € N, written 
G = (N,E,s,e,L,1), with the following properties: 


e N is the set of nodes and each statement or predicate in p is represented by a 
nodeneN, 


E is the set of edges representing the control flow between nodes, 


s, also called start or entry node, has no incoming edges, 


e, also called exit node, has no outgoing edges, 


Lis a set of labels and! : E — L is a function that maps each edge to a 
label. 


The labels are used to model conditional flows. As they do not play an 
important role in this thesis, I will mostly ignore them in the following. 
For intraprocedural graphs that are considered in isolation, a classical 
assumption is that for all n € N there is a path which starts ats and ends at 
n. 

In the literature there is some variation in the concrete representation 
of control-flow graphs. Some authors [12, 106, 130] use a node-oriented 
notation, in which the nodes of the control-flow graph represent the 
statements, while others [46, 153, 127] use an edge-oriented notation, in 
which the edges are annotated with the statements. Also, there are 
some differences among the node-oriented notations: some of them use a 
different node for each statement, while others use nodes for each basic 
block, which are linear chains of statements. 

I use a node-oriented notation of control-flow graphs in this thesis. 
Moreover, I will only consider basic blocks with one statement, unless I 
deviate from this convention explicitly. 
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3.2.1.2 Interprocedural Control-Flow Graphs 


For programs with multiple procedures, control-flow graphs have to be 
adapted in order to model the procedure calls properly. Again, there 
are several notions in the literature, which differ slightly. In most of 
them, interprocedural control-flow graphs are families of intraprocedural 
control-flow graphs for each procedure. They mainly differ in the exact 
way in which they model calls and whether the procedural control-flow 
graphs are connected or not. 

My definition follows notations used by De Sutter et al. [51] and Hammer 
[86]. 


Definition 3.2. Let Proc be a finite set of procedures with main € P. An 
interprocedural control-flow graph (ICFG) is a quadruple 


G= ((Gp) peProcr Ecall» Eret, ®) 


For every p € Proc, Gp = (Np, Ep, Sp, ep) is an intraprocedural control-flow 
graph. For different procedures p, p’ € Proc, the corresponding control-flow 
graphs Gp and Gy are disjoint: Np ONy = Band EyNEy = 0. If 
e € Ep for some p € Proc, e is called intraprocedural edge. The set of 
intraprocedural edges is denoted by Ejntra- 


Eats Eret < Upp Np X Ny — The elements of Ecay are called call edges 
and the element of Eye: are called return edges. There is a bijective function 
® : Ecaıı > Erer which maps call edges to their corresponding return edges 
(and vice versa). This function is also called correspondence function. 


o Ifn n’ € En, then there are p,q € Proc such that n € Np \ {ep} and 
n’ = sq. For eca € Eca, I call src(e) a call node. 


o Ifn > n’ € Ere, then there are p,q € Proc such that n = ep and 
n’ € Ng \ {eg}. For eret € Eyet, I call tgt(e) a return node. 


Call nodes have, apart from call edges, no further outgoing edges. 


Return nodes have, apart from return edges, no further incoming edges. 


Figure 3.4 shows how procedure calls can be modeled: Each call is 
represented by two nodes, one for the call itself and one for the point just 
after the call to which the called procedure returns. I call this point the 
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return 
site 


Figure 3.4: Additional control-flow structure for procedure calls 


return site. A call edge cay connects the call node with the entry node of the 
callee and a return edge eret connects the exit node of the callee to the return 
site. These two edges correspond to each other, i.e. ©(e..11) = Eret- 


3.2.2 Data-Flow Analysis 


In this subsection, I introduce data-flow analysis, a classical static program 
analysis technique. My presentation roughly follows textbook literature 
[152, 130] and classic articles [102, 82, 101, 46] on the topic. 

Roughly, data-flow analysis gathers information about the possible exe- 
cutions of a program. This information can then be used in subsequent 
analyses and program transformations. 

Before I introduce data-flow analysis in the following, I want to consider 
the paths of control-flow graphs more closely. 

A usual assumption about control-flow graphs, which I also make in this 
thesis, is that they are sound. This means that, given the control-flow 
graph G of a program P, every execution of P is represented by a path in G. 
Note however, that this representation is not always exact. For example, 
a common simplifying assumption is that all outgoing edges of a given 
node might be taken by some program execution, regardless of the path 
that an execution had taken before. 

An example of what this means can be seen in Figure 3.5. 
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Assuming that statement S does not change the outcome of b it is clear 
that no program execution can take the path 1 > 2 — 6 — 7. Since 1 > 2 
is only traversed if bis evaluated to true at 1 and s does not change the 
outcome of b, any execution that traverses 1 — 2 must traverse 6 > 9 
after that. Analyses that take into account the histories of paths are also 
called path-sensitive. Several publications on path-sensitive analysis can be 
found in the literature [89, 54, 35, 49]. In this thesis, I will only consider 
path-insensitive analyses. 


3.2.2.1 Intraprocedural Data-Flow Analysis 


In the following, I concentrate on intraprocedural data-flow analyses that 
only consider a single procedure. The notions that I introduce however are 
also useful for interprocedural data-flow analysis, which I will describe in 
subsubsection 3.2.2.2. 

A data-flow framework is a pair (L,F) that specifies the general structure 
of the data-flow analysis to be performed. The set L describes how 
information look like, while F is a set of functions on L which transform 
this information. 

A data-flow analysis associates each node n in a given control-flow graph 
with some property of the control-flow paths from the graphs start node 
to n. 


(a) 


Figure 3.5: A code snippet and its control-flow graph 
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The elements of L are used to represent properties like “a is definitely 42”, 
“the value of b is unknown” or “variable c has the value assigned to it in 
line 5”. Such properties can be partially ordered with respect to the amount 
of information they provide. For example, if x represents the property 
“a is definitely 42” and y represents the property “a has an unknown 
value”, then x can be considered to provide more information than y, 
which is formally expressed by x < y. Because we want to propagate 
information along the paths of a given control-flow graph, we need a way 
to combine values coming from different paths. The value resulting from 
a combination of x, y € L should provide at least as much information as 
the combined values but can provide no more information, in order to be 
safe. So a good candidate for such a combination is the least upper bound or 
joins of x and y, In order to have a well-defined structure it is customary to 
require L to have least upper bounds for arbitrary subsets A < L. In other 
words, L is assumed to be a complete lattice (see page 15). 

The transfer functions are abstractions of the program’s statements’ effect 
on properties? . They are assumed to be information-preserving, that is, 
if x provides more information than y, then the same should hold for 
the transformed values. Formally, this means that transfer functions are 
monotone. Additionally, it is customary to require that F enjoys some closure 
properties: Usually, one assumes that F contains the identity function and 
is closed under composition and arbitrary joins. Since the set of monotone 
functions L — L has all these properties, F can in theory be assumed to 
contain all monotone functions. In practice however, this set is usually “too 
large” in the sense that it contains more functions than actually needed 
for the given data-flow analysis. Hence, one aims to find more precise 
descriptions of F that allow for effective or even efficient representations. 
Classically, a data-flow framework is thought to be independent of the 
control-flow graphs they work on. To actually perform a data-flow 
analysis on a given control-flow graph, a data-flow framework needs to be 
instantiated. 

Hence, a data-flow instance is a quintuple (L,F,G, p, init) that adds to a 
data-flow framework (L,F) a control-flow graph G = (N,E,s,e) connects 
the two using (a) an initial information init € L that represents the properties 


>The area of abstract interpretation is concerned with the systematic derivation of transfer 
functions from program semantics [46]. 
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which hold at G’s entry node s and (b) a function p : E — F. This function 
associates each edge® e with a transfer function p(e) that describes the 
effect of the statement src(e) on the properties in L and init € L. Instead of 
p(e), Lalso write fo. 

By induction, transfer functions can be extended to the paths of G: 


fe =id 
fre = fe o fn 


Due to the closure properties of F, all fr are elements of F. 

The functions fr describe how properties are transformed along control- 
flow paths. We are interested in the properties which hold at each node, 
no matter which path was taken. For this purpose, we take the least upper 
bound of all fr and apply this function the initial information init. The 
result of this operation is also called the merge-over-all paths solution 


(3.1) MoP(n)= || rnit), 
) 


nePathsg(n 


where Pathsg(n) is the set of paths in G from s to n. 

The function MOP is in some sense the ideal solution of the given data- 
flow analysis problem, so the goal of data-flow analysis is to compute 
MOP. Note that MOP cannot be computed directly using (3.1), since (3.1) 
potentially merges over infinitely many paths. Also, there are data-flow 
instances for which MOP is not computable at all [101]. However, there 
are sufficiently interesting and useful data-flow frameworks for which it is 
possible to compute a safe over-approximation of the corresponding MOP 


6It may seem odd that in the formalism I use in this thesis, statements are represented by 
nodes but, in contrast, transfer functions are associated with edges. This “hybrid” variant of 
data-flow analyses, however, can also be found in the literature [82, 136], just like the “pure” 
variants that either associate both statements and transfer functions with nodes [102, 100, 10, 
106] or edges [46, 153], respectively. All three variants appear to be equivalent. My decision 
is mostly for pragmatic reasons: Although I prefer to associate transfer functions with edges, 
I want to describe control-flow graphs and program dependence graphs uniformly and 
acknowledge that in previous work [58, 93], program dependence graphs are derived from 
control-flow graphs in which the nodes represent statements. Hence I inherit node-oriented 
control-flow graphs from these earlier presentations. 
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solution. A safe over-approximation is a function A: N —> L that has the 
property 


(3.2) Yn € N. A(n) > MOP(n). 


This property is equivalent to 


(3.3) Yn € N. V7 € Pathsg(n). A(n) = fr (init). 


Property (3.3) says that for every n € N and every n € Pathsg(n), A(n) 
can provide no more information than fr (init). This is safe in the sense 
that no piece of information coming from a path ending in n is left out of 
A(n). A program optimization (or any other program transformation) that 
solely relies on the information provided by A never changes a program’s 
behavior, provided that the transfer functions make sure that the program 
semantics is abstracted faithfully. 

For instance, suppose that a compiler aims to identify variables that always 
have the same values in order to substitute read accesses by the constant 
value. A possible data-flow analysis for this would then propagate along 
a control-flow path nz whether the value of variable x stays the same on 
n (and the value itself, if applicable). Then A(n) says something about 
whether x always has the same value on any control-flow path ending in 
n and provides this value, if applicable. But then A(n) has to integrate 
the information of all paths ending in n. Otherwise, A(n) could express 
that x’s value is always the same up until n but ignores some of the paths 
where the value of x is indeed different, which means that A(n) makes an 
unsafely wrong statement about the program under analysis. Clearly, the 
optimization step that substitutes accesses to x with the value computed 
by A would result in a program that differs in behavior from the original 
program. 

A trivial safe over-approximation of MOP is the function which returns T 
for every n. This is of course safe because T provides no information at 
all. For our example, A(n) = T would mean that variable x may assume 
different values during program execution, even if this is not the case. 
Clearly, this may also be a wrong statement about the program under 
analysis but this time it can be considered safe because A(n) provides no 
information that can be exploited by the subsequent optimization step. 
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This leads to a notion of precision specialized to data-flow analysis: For 
two safe over-approximations A and B, A is at least as precise as B if 
Yn € N. A(n) < B(n). In other words, for every n € N, A needs to provide 
at least as much information as B. 

In general, one aims to obtain a safe over-approximation for MOP which 
provides as much information as possible. One way of obtaining such a 
solution is to solve the following system of monotone constraints: 


Constraint System 3.1. 
A(s) > init 
m&n = A(n) > fe(A(m)) 


The idea of this system is to build up MOP “edge by edge”. 
By grouping together constraints with the same left-hand side, we can 
transform this constraint system to a system with one constraint per node: 


A(n) 2 Fa((A(m))men): 


Each F, : LNI — L is monotone. 
The whole constraint system can be described by one constraint 


(3.4) A > F(A) 

where 

(3.5) F:(N>L)> (N >L) 
(3.6) F = (Fn) nen 
(3.7) Fn(A)= | | £(A(m)) 


Since L is a complete lattice, N — L is, too. Moreover, F : (N > L) > 
(N > L) is monotone. 

In order to solve the constraint system, we need to find a function A : N > L 
that satisfies (3.4). 

The theory of complete lattices tells us that this is always possible: The- 
orem 2.1 implies that (3.4) has a unique least solution, that is a solution Ag 
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MOP(n4) = fa(fi(init)) U fa(falinit)) 
MFP(n4) = fs (fı (init) U fa (fa (init) )) 


Figure 3.6: Illustration of the effect of non-distributivity on the difference between 
MOP and MFP, based on Constraint System 3.1 


such that Ag < A for every solution A of (3.4). So, Ag is the most precise 
solution of (3.4). In the context of data-flow analysis, Ag is also referred to 
as Minimal Fixpoint, or MFP for short. 


Furthermore, it can be shown that Ag is a safe over-approximation of MOP: 


Ao = MOP. 


Moreover, Theorem 2.13 states that Ag can be computed using Algorithm 3, 
provided that L satisfies the ascending chain condition (see page 16). 
Note however, that MFP in general does not coincide with MOP. This is 
only the case if all the transfer functions enjoy a property that is called 
distributivity: A function f : L — L is distributive, if 


VACL. fi |A)=| | F(A) 


Whereas MOP first applies all transfer functions along the different paths, 
MFP applies joins at each node, for results along the incoming edges. In 
non-distributive instances, it is impossible to “pull joins out of” functions, 
which prevents MFP from coinciding with MOP. This is illustrated in 
Figure 3.6. 

As an example of intraprocedural data-flow analysis, I want to discuss 
reaching definitions. This is a standard data-flow analysis applied in 
compilers and can also be used to compute data dependencies (see para- 
graph 3.3.2.1.1). 
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A(entry) 20 node |value 

A(1) > A(entry) entry | 

AB) 2 (A(1)- (4) UT 1 | 

A(3) > A(2) 2 | 

AB)  2A(2) 3. m 

A(6) 2 (A(5) - 5,10}) U {5} 5 {1} 

A(7) 2 (A(6)-{6,11))U {6} 6 LE 

A(8) 2 (A(7)-{7,12}) U7}. 7 5,6} 

A(9)  2(A(8)-{8,13)U{8} 8  |15,6,7) 

AO) —- 2 (A(13) -{8,13}) {13} 9 |{1,5,6,7,8,10,11,12,13) 
A(10) 2 A(9) 10 |{1,5,6,7,8,10,11, 12, 13} 
A(11) 2 (A(10) —{5,10}) U{10}. 11 |f1,6,7,8,10,11,12,13} 
A(12)  2(A(11)-{6,11})U{11} 12  \{1,7,8,10,11,12,13) 
A(13)  2(A(12)-{7,12})U{12} 13  |{1,8,10,11,12,13) 
A(15) 240) 15 |{1,5,6,7,8, 10, 11, 12, 13} 
A(exit) 2 A(3) exit /{1,5,6,7,8, 10, 11,12, 13} 
A(exit) 2 A(15) 


Figure 3.7: The constraint system and its least solution for the reaching definition 
analysis applied to the example from Figure 3.3 


Given a control-flow graph G = (N,E,s,e), a definition of a variable x 
is a node n € N which represents an assignment statement x := e. Let 
Def (x) <N be the definitions of variable x and assume for simplicity that 
each statement can define at most one variable. A definition n may reach a 
node n’ if there is a path from n to n’ on which there is (apart from n) no 
further definition of the variable defined by n. 

For n € N, the reaching definitions of n are the definitions which may reach 
n. 
The data-flow framework for reaching definitions consists of (2P, F) where 
DEN is the set of definitions in N, partially ordered by &. F consists 
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of functions of the form AA. (A — K) UG where K,G < D are sets’ of 
definitions. It can easily be verified that F contains the identity function 
and is closed under composition and joins. 


Let m -5 n be an edge in G. Then m’s effect on the reaching definitions 
can be described as follows: If m is not a definition, then every definition 
which reaches m also reaches n. Therefore, all definitions reaching m are 
propagated to n. If m is a definition of variable x, then every definition 
of some variable x’ # x is propagated to n, but since m (re-)defines x, 
all previously reaching definitions of x are deleted and replaced by m. 
Formally, the edge transfer functions fe are defined by 


fe AA. A if m does not define any variable 
©" )AA. (A-Def(x)) U{m} ifm is a definition of x 


Since initially no variable is defined, the initial information init is 0. 

For the example program from Figure 3.3, the monotone constraint system 
resulting from the corresponding data-flow instance and its least solution 
is shown in Figure 3.7. 


3.2.2.2 Interprocedural Data-Flow Analysis 


Like intraprocedural data-flow analysis operates on intraprocedural 
control-flow graphs, interprocedural data-flow analysis operates on inter- 
procedural control-flow graphs. 


3.2.2.2.1 Context Problem Interprocedural control-flow graphs intro- 
duce a source of imprecision, which I already discussed in section 3.1. It is 
caused by a main benefit of having procedures in the first place, namely 
by the fact that procedures can be called from multiple call sites. 

As an example, consider the program in Figure 3.8a. It contains a function 
f that is called from two call sites. Its control-flow graph is shown in 
Figure 3.8b. The graph contains for example the path mı : 1 > 2 > 
7 — 8 > 9 — 3, which corresponds to the normal execution of the given 


7Data-flow analyses where the transfer functions can be expressed in this way are also 
called gen/kill or bit vector analyses. 
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void main(int x, int y) { 
a = f(x); 
b = f(y); 


int f(int z) { 
return Z; 


} 


(a) 


Figure 3.8: A small program with its interprocedural control-flow graph with 
(2 > 7) =9 > 3and ®(44> 7) =9 5 


program. However, another path is m : 1 > 2 > 7 > 8 > 9 — 5. This 
path does not correspond to any execution because it does not respect the 
semantics of procedure calls: When a procedure is called, the site from 
which the call is performed is pushed to the call stack. Once the procedure 
is finished, the call is popped off the call stack and execution continues 
from that call site. The path 72 obviously does not respect this semantics: 
No execution that enters f through 2 — 7 leaves it through 9 — 5. 
Relating calls and returns to one another is the main task of the corres- 
pondence function ®. In the example, ® is given by ®(2 > 7) =9 > 3 
and ®(4 > 7) =9 55. 

This leads to the notion of interprocedurally valid paths. Intuitively, an 
interprocedurally valid path is a path that respects the semantics of 
procedure calls. Validness can be defined with the help of ®: We say that 
a path 7 is valid if ® (e411) = eret for all pairs (esai, rer) on path such that 
eret is the return that finishes the procedure call performed by eca11- 
Consider the path 7; in the example. The return edge 9 — 3 finishes 
the call that is started by 2 > 7 and the return edge 9 > 5 finishes the 
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call that is started by 4 > 7. According to the definition of ®, we have 
(2 > 7) =9 > 3and ®(4 > 7) = 9 > 5, hence 7 is valid. 

By contrast, 72 is not valid, since 9 — 5 finishes the call that is started by 
2 > 7 but we have ®(2 — 7) #9 > 5. 

In chapter 5, I will consider valid paths in a more general context. In 
particular, I will make precise what I mean by “eret finishes the call that is 
started by en”: 


3.2.2.2.2 Two Approaches for tackling the Context Problem 

From the previous considerations, it is clear that if we perform data-flow 
analysis on interprocedural control-flow graphs like we do on intrapro- 
cedural control-flow graphs, the result is overly imprecise: Even if MFP 
coincides with MOP, the result is still imprecise since MOP merges over too 
many paths. To increase precision, we can consider a version of MOP that 
ignores paths that are definitely invalid. To define that, we let VP(n) be the 
set of valid paths that start in Smain and end in n. Now let (L, F,G, p, init) 
be a data-flow instance. 

Then we can define the merge-over-all-valid-paths MOVP as 


(3.8) MovP(n) = | | fa (init) 
neVP(n) 


Sharir and Pnueli [154] presented two approaches to compute MOVP and 
showed that these two approaches compute under certain assumptions 
the same solution. In the following two sub-paragraphs, I give a short 
summary on both of these approaches. I will also consider both approaches 
in chapter 6 and chapter 7 in a more general setting and in more detail. 


Call-String Approach The idea of the call-string approach is to ex- 
tend the constraint system that describes MOP by an additional stack 
component. Every time a call is encountered, this call is pushed onto the 
stack and each time a return is encountered, it can be checked whether 
it corresponds to the call at the top of the stack. Constraints are only 
generated for corresponding call-return pairs. 

More formally, the constraint system describes a function 


A:NxS-L 
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where S = E* „ is the set of all call stacks. The intraprocedural constraints 
naturally extend the constraint system given for intraprocedural data-flow 
analysis. Constraints for call and return edges not only apply the transfer 
functions but also manipulate the call stack according to procedure calling 
semantics, using the usual stack operations push, pop and top, with the 
properties 


push(e,o) =e- o 


pop(e:0)=0 
top(e-o) =e 


The empty stack is denoted by e. The full constraint system C stack looks as 
follows: 


Constraint System 3.2. 
A(s,€) > init 
mone € Enna => A(n,o) > fe(A(m,o)) 
monde € Ecqy — Aln,push(e,o)) > fe(A(m,o)) 


monhe€EmAo#E > 
le = Alr poplo) = fC ACen) 

Note the additional precondition for the return constraints: No constraint 
is generated if ®(top(o)) # e. This ensures that the resulting function A 
does not mix up calling contexts. 
Like in the intraprocedural case, the above defined constraint system C stack 
has a least solution Ag. 
To ensure comparability with MOVP, we define 


Aln) = |_| Ao(a,0). 

ces 
Then it turns out that Ag > MOVP and that Ag = MOVP under some 
additional assumptions. However, there is one hitch: Unlike the intrapro- 
cedural constraint system, Constraint System 3.2 cannot be computed by 
the usual method, particularly if the program contains recursive calls. 
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A) A(r) 2 fere (fo Pecan A) 
(2) Als) > fecan(A(c)) 


(a) (b) 


Figure 3.9: Sketch of the idea of the functional approach 


The reason simply is that Constraint System 3.2 is not guaranteed to be 
finite. 

The usual solution is to restrict the depth of the stacks. So instead 
of computing a function in N x Et — L, we compute a function in 


N x ESK 


call > L and an adjusted push function 


push,(e,0) = (e-0)<* 
that discards the lowermost item on the stack o if o already has k elements. 
By using push, instead of push, Constraint System 3.2 is always finite, its 


(k) 


least solution A, ’ can be computed using the usual method and still has 


the property Ay > MOVP. However, note that discarding parts of the stack 
does not yield a fully context-sensitive analysis. 


Functional Approach The functional approach uses the following idea, 
which is illustrated in Figure 3.9: Suppose that we have for each procedure 
p a transfer function fp that faithfully describes a complete traversal of a 
procedure p’s control-flow graph. Then we can obtain a context-sensitive 
constraint system as follows: For normal intra-procedural edges, we use 
the usual constraints. For each call site c of p we can use fp to describe the 
effect of a call of f at c with a constraint like (1) in Figure 3.9b. 
Additionally, a constraint like (2) ensures that the data-flow information is 
propagated from each call site to the entry of p. 

Now, because of constraint (1), no constraint of the form 


A(r) 2 Feret (A(t)) 


59 


3 Program Dependence Graphs for Object-Oriented Programs 


is needed to propagate data-flow information back to the return site r. Such 
a constraint would introduce the context problem because the data-flow 
information at t subsumes all paths to t. This includes in particular the 
paths which come from call sites other than c. Information along these 
paths is not supposed to be propagated to r. Constraint (1) avoids this 
problem by propagating the information at c through the whole procedure 
p. 

It remains to solve the sub-problem of providing the fp. The idea is to 
describe them by a monotone constraint system, just like the final solution 
of the overall data-flow analysis. Note however that the fp do not represent 
single data-flow information but describe how data-flow information is 
transformed. This means that the fp do not live in L but in F. 

As I already mentioned above, any fp should faithfully describe a complete 
traversal of p. More formally, this means that the f, incorporate the effects 
of traversing a certain class of paths from p’s entry to its p’s exit, the 
so-called same-level paths. A same-level path is a path that leaves every 
called procedure at the right call site and, additionally, ends in the same 
procedure in which it started. Hence a same-level path from p’s entry to 
p’s exit can be considered a complete traversal of p, as it may also occur in 
a real execution. 

The sets SL(Sp, t) of same-level paths from Sp to t € Np are defined induct- 
ively for procedure entries sp and nodes t € N, of the same procedure. In 
order to avoid that call sites are mixed up, only corresponding call and 
return edges can be appended. 


(3.9) e € SL(Sp,Sp) 
(3.10) n E SL(sp t) At "8" ey = Teira € SL(5p,t’) 
® 
(3.11) ne SL(sp, t) At E Sp! A'E SL(sp ep) A ep Cecon) t” 


=> T: call I: P (ecan) € SL(Sp, t”) 


Using the same-level paths, we can now specify what we expect of the fp: 
The fp shall incorporate the effects of traversing any same-level path: 


fo Z || fr 


neSL(sp,ep) 
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The constraint system for the fp can defined along the same-level paths as 
follows: 


Constraint System 3.3. 


(3.12) X(Sp,Sp) 2 id 
(3.13) t5 t Ae € Eintra = X(8p,t’) 2 feo X(5p,t) 
t u Sp! 
(3.14) Necat € Ecall ==> X(Sp,t’) > fæle) X (Spr ep’) Fe X (Sp, t) 
hey Pail) y 


Both Constraint System 3.3 and the one sketched in Figure 3.9b are finite, 
even in the presence of recursion. This means that, if the complete lattice 
NxN —> Fsatisfies the ascending chain condition, it can be solved by Algo- 
rithm 3. Note however that this additional condition restricts the practical 
applicability of the functional approach in comparison to the restricted 
call-string approach: It can only be applied to data-flow frameworks in 
which not only the complete lattice L but also the function space F satisfies 
the ascending chain condition. However, if the functional approach is 
applicable, it obtains a fully context-sensitive solution. 


3.3 Slicing on Program Dependence Graphs 


In this section, I introduce slicing, another important static program analysis 
technique, and program dependence graphs, a data-structure that reduces 
slicing to graph reachability. 

This section is organized as follows: First, I explain the general idea 
of slicing in subsection 3.3.1. In subsection 3.3.2, I introduce program 
dependence graphs, first for the intraprocedural case and subsequently for 
the interprocedural case. Finally, in subsection 3.3.3 I show how program 
slicing can be performed on program dependence graphs. Specifically, I 
consider an approach to obtain context-sensitive slices on interprocedural 
program dependence graphs. 
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3.3.1 Slicing 


Program slicing was introduced by Weiser [165] as a technique for focusing 
on specific parts of a program. For a given program P, a slice is defined 
with respect to a slicing criterion which consists of a program location | 
and a variable x. Given such a slicing criterion c = (x,1), a valid slice 
with respect to c is any sub-program P’ of P which produces the same 
behaviour with respect to c as P. This means that if P and P’ are started in 
the same state and both terminate, then P and P’ cannot be distinguished 
by just looking at the values of x at each respective execution of location |. 
It is desirable to have an automatic procedure which can always find 
slices of the smallest possible size. Due to decidability reasons, such a 
procedure cannot exist, but Weiser [165] describes a procedure to obtain a 
valid program slice that is fairly small. The idea is roughly to traverse the 
program’s control-flow graph backwards from the given slicing criterion 
(x,1) and include in the slice every statement which may have an influence 
on the value of x in l. Essentially, Weiser’s procedure transitively follows 
the data and control dependencies ending in x backwards. 


3.3.2 Program Dependence Graphs 


Program Dependence Graphs [58] (PDGs) are another program representation 
used in program analysis. Roughly, PDGs model the dependencies between 
the statements and expressions of a program. 

Ferrante, Ottenstein and Warren [58] introduced the program dependence 
graph as a program representation which makes control dependencies and 
data dependencies explicit. On this representation, program slicing can be 
expressed as a graph traversal. A slice thus obtained is indeed valid [140]. 


3.3.2.1 Intraprocedural Program Dependence Graphs 


For intraprocedural programs, there are two main kinds of dependencies: 
data dependencies and control dependencies. In the following, I will briefly 
explain data and control dependencies. After that, I will show how 
Program Dependence Graphs are extended for programs with multiple 
procedures. 
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__ path without 
re-definition of x 


Figure 3.10: Visualization of data dependencies 


3.3.2.1.1 Data Dependencies Data dependencies capture the flow of 
data inside a program. A statement defines a variable if it writes a value 
to it and uses a variable if it reads the current value of that variable and 
then uses this value, for example to define other variables or to evaluate a 
branching condition. 

For a statement (or CFG node, respectively) s I denote with de f(s) the set 
of variables defined by s and with use(s) the set of variables used by s. 
Basically, a statement or expression sz is data-dependent on statement s4 if 
there is a variable x such that (1) sı defines x, (2) s2 uses x and (3) there is a 
control-flow path between sı and sz that does not define x. Such a situation 
is illustrated in Figure 3.10. Definition 3.3 gives a formal definition. 


Definition 3.3 (data dependencies). Let G = (N,E,s,e) be a control-flow 
graph. n € N is data-dependent on m € N, written m gg n, if there is 
x € def (m) N use(n) and there is a path n € Pathsg(m,n) such that Y1 <i < 
\n|-1. x ¢ def (ri). 


Figure 3.11 shows the data dependency graph of the program from Fig- 
ure 3.3. 

For example, there is a data dependency from line 5 to line 7 because line 5 
defines the variable a, line 7 uses a and a is not overwritten between line 
5 and line 7. In contrast, line 5 and line 12 are not connected by a data 
dependency: Though line 12 uses a to define c, it definitely does not use 
the value of a from line 5, since a is overwritten in line 10. 

Data dependencies can be computed using the reaching definitions analysis 
described earlier. 


3.3.2.1.2 Control Dependencies The other kind of dependencies in a 
program dependence graph are control dependencies. The intuition behind 
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control dependencies is illustrated in Figure 3.12. Control dependencies 
capture that a node m € N is the “latest” node that “decides” whether 
(or how often) a node n is executed or not. This means that if program 
execution traverses m, then it can either proceed to a branch from which m 
can be bypassed or to a branch from which the execution of n is inevitable. 
Throughout this thesis, I assume the classical definition by Ferrante et 
al. [58], which I present here for reference. Ferrante et al. also propose 
an efficient algorithm for computing control dependency graphs that 
constructs the post-dominator tree using a fast algorithm presented by 
Lengauer and Tarjan [119]. 


Definition 3.4 ([58], Definitions 2 and 3). Let G = (N,E,s,e) bea control-flow 
graph and m,n € N. 


1. Node n post-dominates m if 


Yr € Pathsg(m,e). n € nodes(1) 


2. Node n is control-dependent on m, written m >.q n, if 


a) there is a path n € Pathsg from m ton such that n post-dominates every node 
in rı (except for m and n) 


b) n does not post-dominate m. 


Figure 3.13 shows the control dependence graph of the example from 
Figure 3.3. 


(1 : read(n) 


(2: n< 1) [3: print(n))(9: i < n) 


Figure 3.11: Data dependency graph for the example from Figure 3.3 
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ncan be n is inevitable 


skipped 


Figure 3.12: Illustration of control-dependencies 


start 


5:a=0) (6 b=1)(7:c=at+b)(8i=0) (isn 


end 


3: print(n) 15: print(c) 


(10:a=b) (11: b=c) (42: c=a+b\ 13: i=i+1) 


Figure 3.13: Control dependence graph of the program in Figure 3.3 — note that 
for well-formedness reasons an additional synthetic control-flow 
edge between the entry node and the exit node is assumed 


3.3.2.2 Interprocedural Program Dependence Graphs 


In the following, I describe briefly how Program Dependence Graphs look 
like for programs with multiple procedures. The standard approach has 
been described by Horwitz et al. [93]. 

In this approach, interprocedural PDGs are constructed from intrapro- 
cedural PDGs in a similar way as interprocedural control-flow graphs are 
constructed from intraprocedural control-flow graphs. An interprocedural 
PDG consists of a PDG for every procedure. These procedure dependence 
graphs are enriched with additional nodes and edges which model the call 
itself and the passing of parameters from caller to callee and the passing 
of return values from callee to caller. This modelling assumes call by 
value. First of all, a call dependence connects the call node at the call site 
and the entry method of the callee. This is a special control dependence 
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call / parameter-in / -out 
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Figure 3.14: The interprocedural PDG of the example in Figure 3.8a 


that captures the intuition that the call node “decides” whether the callee 
is called or not. 

Moreover, for every parameter of a procedure p, there is a formal-in 
parameter node, and for its return value, there is a formal-out node. At each 
call site of p, there is an actual-in node for each of p’s parameters and an 
actual-out node for p’s return value. Formal and actual parameter nodes are 
connected via parameter-in and parameter-out edges, which model passing 
of parameters from caller to callee and of the return values from callee to 
caller. A procedure call can be thought of to be preceded by a series of 
assignment statements which assign the actual parameter values to special 
variables which only the callee has access to. After the procedure has 
finished, it copies its return value to a special variable which only the caller 
has access to. In this sense, parameter-in and parameter-out edges can 
be seen as special interprocedural data dependencies. Parameter passing 
is then modeled using a parameter-in edge which connects the actual-in 
parameter node at the call site with the formal-in node in the callee. 
Additional parameter-out edges model how data flows from a formal-out 
parameter node of a procedure to its counterpart in the caller. Consider 
for example the interprocedural PDG in Figure 3.14: Procedure f has one 


66 


3.3 Slicing on Program Dependence Graphs 


formal-in parameter node for its parameter z and one formal-out parameter 
node for its return value. Both are connected to their counterparts at each 
of the two call sites of f. 

In the following, I consider call dependencies and parameter-in edges 
as call edges and refer to all call edges as E,,7. Analogously, I consider 
parameter-out edges as return edges and use E;¢; to refer to the set of 
parameter-out edges. 


3.3.3 PDG-based Slicing 


As I already mentioned in the beginning, program dependence graphs 
make explicit the dependencies that are traversed implicitly during Weiser’s 
slicing procedure [165]. Hence, PDGs reduce the slicing problem to mere 
graph traversal. 


3.3.3.1 PDG-based Intraprocedural Slicing 


Algorithm 4: A simple intraprocedural backward slicer - upon 
termination, we have W = BSjnjrq(s) 


Input: a PDG G = (N, E) with intraprocedural edges Ejytra, sli- 
cing criterion se N 
Result: intraprocedural slice BS jn t/q (5) 
1 We {s} 
2 while W #0 do 
3 | ne remove(W) 
4 foreach m > n € Ejntyg do 
5 | We Wu {m} 


6 return W 


For single procedures, PDG-based slicing works as follows: Given a PDG 
G = (N, E) and some node n, the backwards-slice is the set BS(n) € N of all 
nodes that reach n in the PDG: 


BS(n) = {s€ N |s >b n} 
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Analogously, the forward-slice is the set FS(n) < N of all nodes that is 
reachable by n in the PDG: 


di 
FS(n) NiseN|n 55} 
BS and FS are related by the property 
seBS(n) & n € FS(s) 


and hence are dual to each other. Algorithm 4 shows a simple algorithm 
that computes an intraprocedural backward slice of s € N. It is very easy 
to modify Algorithm 4 such that it computes an intraprocedural forward 
slice. 


3.3.3.2 PDG-based Interprocedural Slicing 


Interprocedural slicing operates on an interprocedural program depend- 
ence graph, just like intraprocedural slicing operates on an intraprocedural 
program dependence graph. 


3.3.3.2.1 Context Problem Similar to data-flow analysis, interproce- 
dural slicing faces the problem that not all paths in an interprocedural 
program dependence graph represent a valid chain of dependencies. In 
effect, if BS and FS are not adapted to the interprocedural case, they yield 
context-insensitive slices, which are usually too big. 

For example, Figure 3.15 shows a simple backwards slice of the return 
value of the second call of f from Figure 3.14. This slice also contains the 
actual parameter of the first call of f. 

However, the only path from the actual parameter of the first call of f to 
the return value of the second call of f is interprocedurally invalid - just 
like the path that enters f through the first call site and leaves it through 
the second call site. 


3.3.3.2.2 Context-Sensitive Interprocedural Slicing The context prob- 
lem for interprocedural slicing can be tackled in similar ways as the context 
problem for interprocedural data-flow analysis. Agrawal and Guo [9] 
consider a call-string-based approach that supports call-strings of unlim- 
ited length. However, Krinke [110] observes that this approach is indeed 
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incorrect. He proposes a fixed version and also considers call-strings with 
limited depths. 

Horwitz, Reps and Binkley [92, 93] propose an approach to interprocedural 
slicing that resembles the functional approach for interprocedural data-flow 
analysis and thus avoids the context problem. First, in a pre-processing 
step the program dependence graph is extended with additional summary 
edges. A summary edge is added between an actual-in node and an actual- 
out node of the same call site if a corresponding formal-in/formal-out pair 
is connected by a chain of intraprocedural edges or summary edges. The 
resulting graph is called System Dependence Graph. 

In comparison to the original presentation [92, 93], the runtime performance 
of the pre-processing step can be improved by introducing additional book- 
keeping and trading space for speed, as shown by Reps, Horwitz, Mooly 
and Rosay [137]. My presentation in this thesis concentrates on the 
improved version. 

The actual slicing can then be performed on the System Dependence 
Graph using an algorithm that operates in two phases. Each phase 
basically consists of a simple graph reachability approach that skips either 
parameter-in or parameter-out edges. Both phases use summary edges to 
traverse call sites. This way, the approach avoids traversing call and return 


| 
I 
' [frm-in] [frm-in 
l 
l 


à 
act-out 
ret 


Figure 3.15: Context-insensitive backwards slice of the actual-out ret parameter 
of the second call of f 
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edges individually - the root cause of the context problem, as I mentioned 
earlier. 

Similar to the functional approach to interprocedural data-flow analysis 
described in section 3.2.2.2.2, summary edges describe a complete traversal 
of the called procedure and the System Dependence Graph is nothing more 
than the integration of these additional helper transfer functions into the 
Program Dependence Graph. 

More generally, the PDG edges themselves also can be viewed as transfer 
functions. The information they propagate is mere reachability. In this 
sense, the two-phase slicer can be understood as the solution algorithm for 
a data-flow analysis instance with very simple transfer functions. I will 
discuss the similarities between and differences of data-flow analysis and 
slicing in more detail in subsection 3.3.4. 

In the following, I briefly describe the summary edge algorithm and the 
two-phase slicer. 


Summary Edges The summary edge computation algorithm pro- 
posed by Reps et al. [92, 93] is shown in Algorithm 5. The rough idea 
is to compute all node pairs for which there is a same-level path in the 
given program dependence graph. To define same-level paths for program 
dependence graphs, some modifications are necessary: For one, we need 
to use parameter-in edges instead of call edges and parameter-out edges 
instead of return edges. Moreover, the correspondence function needs to 
be a correspondence relation, since in the presence of multiple parameters, 
there may be more than one parameter-out edge that corresponds to a 
given parameter-in edge. In chapter 5, I will present a definition that 
applies to both control-flow graphs and program dependence graphs. 
The algorithm maintains two sets of node pairs (v, w) where w is a formal- 
out node and v is an arbitrary node of the same procedure. If (v,w) € 
PathEdge, then there is a same-level path between v and w. If (v,w) € W, 
then there is a same-level path between v and w and (v,w) has been 
discovered for the first time. 

Initially, for every formal-out node w, the pair (w, w) is contained in both 
W and PathEdge. This is because the empty path is a same-level path. 

In the main iteration, the algorithm removes a pair (v,w) from W and 
reacts to two relevant cases for (v, w): 


70 


3.3 Slicing on Program Dependence Graphs 


Algorithm 5: Summary Edge Algorithm proposed by Reps et al.— 
compare [137, Figure 5] 
Input: a PDGG 
Result: summary egdes in G 
1 PathEdge — © 
2 SummaryEdge — 0 
3 Wep 
4 foreach w € FormalOuts(G) do 


5 
6 


PathEdge — PathEdge U {(w,w)} 
W e WU {(w,w)} 


7 while W + Ø do 


(v, w) — remove(W) 
if v is a formal-in node then 


param-in param-out 
foreachx > vw — ydo 


if x and y belong to the same call-site then 
SummaryEdge — SummaryEdge U {x > y} 
foreach a such that (y,a) € PathEdge do 
if x > a ¢ PathEdge then 
PathEdge — PathEdge U {(x,a)} 
| WeWU{(x,a)} 


else 

foreach x > v € Ejytra do 

if (x,w) € PathEdge then 
PathEdge — PathEdge U {(x,w)} 
W<-—WU{(x,w)} 


if v is an actual-out node then 

foreach (x,v) € SummaryEdge do 

if (x,w) ¢ PathEdge then 
PathEdge — PathEdge U {(x,w)} 

i W e Wuf{(x,w)} 


27 return SummaryEdge 
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dep. 
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Figure 3.16: The interprocedural PDG of the example in Figure 3.8a with sum- 
mary edges 


1. If vis a formal-in node, then a same-level path has been completed. 
The algorithm then adds a summary edge between every corresponding 
actual-in/actual-out pair (x, y). In this context, this means that there is a 
parameter-in edge from x to v, a parameter-out edge from w to y and that 
x and y belong to the same call site. Now that there is an additional edge 
between x and y, it may be the case that some pair (y,a) can be extended 
to (x,a). Because of this, for all already discovered pairs (y,a), (x,a) is 
added to W if it has not been discovered before. This ensures that the call 
site “notices” that propagation can be continued. 


2. If vis not a formal-in node, then every incoming intraprocedural edge 
x — v of vis processed; since there is a same-level path between v and w 
and there is an incoming edge x — v, there is a same-level path between x 
and w. Hence, (x,w) is added to PathEdge and W if it was encountered for 
the first time. If v is an actual-out node, then the algorithm additionally 
processes the already discovered summary edges. 


Applied to Figure 3.14, Algorithm 5 starts at the formal-out return node of 
f and traverses f’s PDG backwards until it arrives at f’s formal-in node for 
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z. Now, a complete same-level path has been discovered and Algorithm 5 
inserts a summary edge between the actual-in node for x and the actual-out 
return node at each of the two call sites of f. This results in the system 
dependence graph shown in Figure 3.16. 


The Two-Phase Slicer 


The idea of the two-phase slicer, which can be 


seen in Algorithm 6, bears some similarity to the idea of the functional 
approach: With summary edges, procedure calls can be skipped. 


Algorithm 6: Backwards two-phase slicer proposed by Horwitz 
et al. [92] 
Input: a PDG G = (N, E); E consists of the intraprocedural edges 


1 
2 
3 


11 


12 
13 
14 
15 
16 
17 


18 


Eintra ANA Eggi, Eret as described on page 67; Esum is the set 
of summary edges as computed by Algorithm 5; slicing 
criterion s 
Result: context-sensitive backwards slice of s 
S<0O 
W, = {s} // phase 1: only ascend to callers 
while W, + 0 do 
n — remove( W1) 
S e SU {n} 
foreach m & n € E do 
if e € Eintra U Esum U Ecay then 
Wı - W1 U Im} 
else 
// e € Eye and m is an exit or formal-out node 
Wz — W2 U Im} 


// phase 2: only descend to callees 
while W2 #0 do 
n — remove(W2) 
S-SUf{n} 
foreach m > n € Eintra U Esum U Erer do 
IR Wo — W2 U {m} 


return S 
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This way, simple graph reachability can be used to obtain a slice that 
respects calling contexts. Note, however, that unlike with data-flow 
analysis, we are not interested in paths from the entry of the main procedure 
but actually want to start at an arbitrary place in the given graph. But 
this means that it does not suffice to descend into called procedures. It is 
also necessary to ascend to calling procedures. For this purpose, the slicer 
proposed by Horwitz et al. consists of two phases: The first phase only 
ascends to calling procedures and the second phase only descends into 
called procedures. 

Figure 3.17 shows how Algorithm 6 is applied to Figure 3.14. The slicing 
criterion is the actual-out return node of the second call of f. In Figure 3.17a, 
we see the state after the completion of the first phase of Algorithm 6: At 
this point, the slice contains all nodes with bold frame. Moreover, the 
actual-out return node of the second call of f is contained in W2 so that 
phase 2 will start with that node. 

Phase 2 then descends into f. The result of this can be seen in Figure 3.17b. 
It can easily be seen that it is more precise than a context-insensitive slice, 
since unlike the slice in Figure 3.15, it does not contain the actual parameter 
of the first call of f. 


3.3.4 Relation of PDG-based Slicing and Data-Flow 
Analysis 


In the following, I investigate the relation between PDG-based slicing and 
data-flow analysis. My observations are 


1. slicing can be cast as a very simple data-flow problem, 


2. this data-flow problem can be solved with basically the same techniques, 
however, different assumptions have to be made, and 


3. particularly, summary-based two-phase slicing can be seen as an ap- 
plication of a modified functional approach to interprocedural data-flow 
analysis 


After having identified slicing as a special case of data-flow analysis, 
we can generalize it and obtain arbitrary data-flow analyses on program 
dependence graphs. These analyses can be solved for instance with the 
functional approach. This will be the subject of chapters 5, 6 and 7. 
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Figure 3.17: Applying the two-phase slicer to the example in Figure 3.14; the slicing 
criterion (with dark gray background) is the actual-out return node of 
the second call of f; nodes in slice after the respective phase have light 
gray background 


In the following presentation, I fix a node se N and consider the forward 
slice FS(s) of s. Note that I knowingly ignore the fact that Algorithm 5 
and Algorithm 6 traverse the graph backwards. In contrast, I only consider 
forward traversals and, in particular, I pretend that Algorithm 5 and 
Algorithm 6 traverse the graph forward. I showed these algorithms in their 
original version that was motivated by applications such as debugging, 
where backward slices are natural. However, in general the propagation 
direction does not matter and can easily be changed. 


3.3.4.1 PDG-based Slicing as a Data-Flow Problem 


As I already mentioned earlier, slicing can be described as a kind of 
reachability analysis. As such, it can easily be cast as a data-flow problem. 
Mainly, we will have to adapt the way in which the constraint systems are 
generated from the given graph. 

Let L = {1, T} with L < T and let F = {Ax.L, Ax.x} with the usual partial 
order. Then (L,F) is a data-flow framework. 
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An instance of this framework is given by the PDG G, the initial information 
init = T and p(e) = id. 
For simplicity, I consider the special case reachability from a given node? s. 


Intraprocedural case For 7 € Pathsc(s,t), we have fr = id. Hence, 
with 


F intra (t) = | fr (init), 
nePathsc (s,t) 


we have Fjytra(t) = T if and only if t € FSintra(s) (where FSintra is the 
intra-procedural forward slice of s). The function Fintra is similar to MOP 
(see (3.1) on page 50), but merges over a different path set. I will examine 
the difference later and ignore it for now. 

Fintra can be described by amonotone constraint system that is very similar 
to the one used in intra-procedural data-flow analysis: 


Constraint System 3.4. 
X(s) > init 
X(t) > X(t’) fort’ St. 


As can easily be seen, this constraint system actually precisely characterizes 
Fintra: Its least solution X can be used to extract the intra-procedural 
forward-slice FSjntrq of s: 


FSintra = {n€ N | X(n) =T}. 


Interprocedural case In the interprocedural case, we want to compute 
Finter( = li Frl T (init). 
neVP(s,t) 


This is similar to MOVP (see (3.8) on page 57). However, there are two 
differences: 


8In later chapters, I consider data-flow problems whose MOP functions take two para- 
meters. 
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T3 


T retum [cat 
72 Tt4 


Tretum 
TI 
s ~~> N10 


Figure 3.18: Illustration of a valid PDG path: The 7; are same-level paths. All n; 
are reachable from s by a valid path. 


1. Finter does not merge over all valid paths starting in Smain and ending in 
t but over those that start in s (similar to Fintra). 


2. Finter refers to a different notion of validness, which I describe in the 
following. 


For interprocedural control-flow graphs, two usual assumptions are 


1. that every procedure p has an entry node s, and each of p’s node is 
same-level reachable from Sp, and 


2. that there is a main procedure main and for each procedure p, Sp is 
reachable from Smain by a descending path, that is a path that consists of a 
series of same-level paths interspersed with call edges. 


In interprocedural data-flow analysis, one usually is interested in proper 
executions that indeed start at Smain and proceed until a given program point 
is reached. This is why MOV P(t) merges over all valid paths from sS,nain to 
t. For slicing, this is different: As we are interested in reachability from s, 
we only want to consider the valid paths that start in s and not necessarily 
iN Singin. Moreover, since s may lie anywhere in the program, the notion 
of validness employed here can not only consider descending paths, like 
in interprocedural control-flow graphs, but also has to include paths that 
have an ascending prefix. Analogously to a descending path, an ascending 
path can be imagined as a series of same-level paths interrupted by return 
edges. A valid path is an ascending path followed by a descending path. 
An illustration is given in Figure 3.18. 

Now we want to describe Fine, by a series of monotone constraint systems. 
We use the functional approach, since it is applicable to the reachability 
framework and we want to maximize precision. Recall that the idea of 
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the functional approach is to avoid traversing call and return edges at 
the same time by first solving a helper system that describes the effect of 
completely traversing procedures from entry to exit. 


Helper System for Same-Level Reachability The helper system is 
similar to the helper system for interprocedural data-flow analysis on page 
61. However, for PDGs we have to make a few modifications: For one, pro- 
cedures may have multiple entries, namely the actual procedure entry and 
the formal-in parameter nodes, and also multiple exits, namely the actual 
procedure exit and the formal-out parameter nodes. Correspondingly, call 
sites may have multiple call nodes (the actual call node and the actual-in 
parameter nodes) and multiple return nodes (the actual return node and 
the actual-out parameter nodes). In particular, the correspondence relation 
® in this case relates actual-ins and actual-outs that belong to the same 
call site and therefore in general is not a function, but rather an arbitrary 
relation. 

With these modifications, the helper constraint system that describes 
same-level reachability looks as follows: 


Constraint System 3.5. 


(3.15) X(n,n) > id 
(3.16) tSt Ae € Eintrag 
=> X(n,t’) > X(n,t) 
(3.17) (eca ere) ed am U ng Any <8 t 


=> X(n,t) > X(no,nı) oX(n,m). 


With uniqueness assumptions of entries, exits, calls and returns in place, 
Constraint System 3.5 reduces to Constraint System 3.3. 

The least solution of this system is a function Xs; : NXN > F with 
X(s,t) = id if and only if t is same-level reachable from s. 

In the following, I show how to use Xs; to actually compute Fine, and 
hence FS(s). The approach exploits a fundamental property about valid 
paths: 

Every valid path n € VP(s,t) is either ascending or there is n € Nea so that m 
can be split up into T4 - T such that T4 is an ascending path from s to n and na 
is a non-empty descending path from n to t. 
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first step: second step: 

compute solution extend solution 

from s from call nodes 

along ascending paths along descending paths 


Figure 3.19: Illustration of how the computation of the reachability solution 
along valid paths works 


I will also call the second kind of valid paths non-ascending. 

As a consequence of the above mentioned property, Finte, can be obtained 
in two steps as illustrated by Figure 3.19. They can be described intuitively 
as follows: 


1. The first step computes the solution along the ascending paths starting 
with s. 


2. The second step starts at the nodes n € N..ı that are reachable from s 
by an ascending path and extends the solution along descending paths. 


Computing Reachability Along Ascending Paths This first step 
works like the intra-procedural case but additionally propagates the 
reachability information along return edges and uses X; for propagating 
from actual-ins to corresponding actual-outs. 


Constraint System 3.6. 


(3.18) Xasc(s) = init 
(3.19) e € Eintra U Ert At’ St 
= Xasc(t) = Xasc(t’) 
(3.20) (eca eret) ED Am B ngan Bt 


=> Xasc(t) 2 Xs, (10,11) ° Xasc(m) 
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The least solution X ‚sc has the property 


(3.21) Xasc(t) #4 > s reaches t using an ascending path 


Extending Reachability Along Descending Paths The second step 
starts at the call nodes that are reachable by ascending paths from s and 
extends the reachability solution along descending paths. Again, it works 
like the intra-procedural case but additionally propagates the reachability 
information along call edges and uses X, for propagating from actual-ins 
to corresponding actual-outs. 


Constraint System 3.7. 


(3.22) aE Nana D thee Egi 
= Xnasc(t) 2 Xasc(4) 
(3.23) e € Entra UEa At’ > t 
= Xyasc(t) = Xnasc(t’) 
(3.24) (ecall, €ret) EP AM a no Any “8 
=> Xnasc(t) = Xs, (0,11) ° Xnasc(m) 


The least solution X \,4sc has the property 


(3.25) Xynasc(t) #4 > s reaches t using a non-ascending path. 


Putting the Steps Together With the fundamental property of valid 
paths and properties (3.21) and (3.25), we can characterize F inter as X sc H 


XNASC: 
(3.26) Finter = Xasc H Xnasc 


3.3.4.2 Comparisons of the Algorithms 


After having compared the specification side of data-flow analysis and 
slicing, I examine the algorithm side more closely. 
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Roughly, one can say that each of the slicers described so far, namely 
Algorithm 4, Algorithm 5 and Algorithm 6, correspond to one or more of 
the constraint systems that I just showed, in the sense that they compute a 
representation of the least solution for significant parts of them. 

In particular, the summary edges used by Algorithm 6 can be considered 
as procedural effect functions that are used to safely skip procedure 
calls, or, for PDGs, transitions from actual-in nodes to actual-out nodes. 
Conceptually, all pairs of actual-in and actual-out nodes at the same call 
site are connected by edges. The presence of a summary edge between 
such an actual-in node m and an actual-node out n encodes whether the 
transfer function for the edge between m and n is Ax.x or Ax.L. In the 
former case, reachability is propagated, in the latter case propagation stops. 
The constraint systems that I showed so far can also be solved with 
appropriate instantiations of Algorithm 3. In the following, I investigate 
the differences between the slicers and Algorithm 3. 

First, when looking at the constraint systems, we see that they are too 
large: They contain a lot more constraints than the ones that are actually 
needed to compute their respective result. An example for this for the 
intraprocedural case can be seen in Figure 3.20: Suppose that the PDG 
contains a node s’ that is not reachable from s but like s has an outgoing 
edge to t. Then both edges are incorporated in Constraint System 3.4 but 
only the edge from s to t is relevant. The other constraint systems have a 
similar problem. 

The reason is that they cannot already incorporate reachability information 
as their purpose is to characterize that very information. An unmodified version 
of Algorithm 3 would solve the complete systems and in particular process 
large parts that are actually not relevant. The slicers however only explore 
the relevant parts of the respective constraint systems, namely the ones 
that are reachable from the initial constraints that do not have variables on 
the right-hand side. 


S~X> 5 
A fe X(t) > X(s) 
t X(t) > X(s’) 


Figure 3.20: Illustration for the way in which the constraint systems for slicing — 
for example Constraint System 3.4 — contain irrelevant constraints 


>X 
>X 
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A striking similarity between Algorithm 3 and the slicing algorithms is 
that they all use worklists to keep track of the items that have yet to be 
processed. However, they differ in what I want to call workflow policy. A 
workflow policy answers the following questions and thus determines 
how the algorithm operates on the worklist to finish its task: 


1. Why is an item put on the worklist? 
2. Which values are updated? 


3. Which items are put on the worklist during processing? 


Figure 3.21 illustrates the differences in the worklist policies of Algorithm 3 
and the slicing algorithms. 

As shown in Figure 3.21a, Algorithm 3 puts an item onto the worklist if 
one of its predecessors has changed in an earlier iteration. Then, when an 
item x is taken off the worklist and processed, its value is updated with 
the value of its predecessors. If the value has changed, all its successors 
are put on the worklist. 

The slicers have a slightly different worklist policy, as illustrated in Fig- 
ure 3.21b. There, an item is put on the worklist if its value has been changed 
in an earlier iteration but this has not been propagated yet. Then when an 
item x is taken off the worklist and processed, all its successors are updated 
with respect to the value of x. All successors whose value changes by this 
are put on the worklist. 

on worklist because 

the value of one 

of its predecessors on worklist because 


has changed before its value has been 
updated before 


value 
is updated from propagates its 
predecessors new value 

if changed to successors 
all successors are 

put on worklist 


(a) (b) 


every successor 
that changed 
is put on worklist 


Figure 3.21: Illustration of the difference between (a) Algorithm 3 and (b) Algo- 
rithm 4 - the node highlighted in gray is assumed to have just been 
taken off the worklist and about to be processed 
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Another difference between Algorithm 3 and the slicers is that Algori- 
thm 3 requires that all variables are processed at least once. For this, the 
algorithm initially puts all variables on the worklist. In contrast, the slicing 
algorithms initialize the worklist only with those variables that are defined 
by initial constraints. 

In short, one can say that the slicers integrate a reachability analysis of the 
constraint system into their solution process. This may seem like a pointless 
observation: For one, reachability analysis is exactly what the slicers do. 
Secondly, data-flow analysis makes several reachability assumptions and 
therefore has no necessity to additionally perform reachability analysis. 
However, this observation is actually helpful for generalizing slicing to 
arbitrary data-flow analysis: Since slicing does not make the reachability 
assumptions of data-flow analysis, its generalization also does not make 
them. Therefore, in order to perform data-flow analysis on program dependence 
graphs that includes slicing as a special case, we need solution algorithms that 
integrate slicing into its solution processing! I will present such algorithms 
in chapter 7, along with the theory that explains why they work and 
what exactly they do. These algorithms can be used to perform data-flow 
analysis not only on program dependence graphs but also on control- 
flow graphs that do not satisfy reachability assumptions such as the ones 
mentioned on page 77. 


3.4 Joana: PDG-based Information Flow 
Control for Java 


In this section, I describe the Joana framework in more detail. 

Joana heavily uses the T.J. Watson Libraries for Analysis (WALA), a 
program analysis framework for Java bytecode [141]. 

Using WALA, Joana applies a wide variety of program analysis techniques 
in order to construct program dependence graphs and to verify various 
non-interference-like properties of a given Java application. Apart from 
the techniques I have shown so far in section 3.2 and section 3.3, Joana 
can also handle modern programming language features. 

The goal of this section is to give the reader a rough understanding of how 
Joana works so that they are equipped to follow the details of chapter 4. 


83 


3 Program Dependence Graphs for Object-Oriented Programs 


For a more thorough description of the inner workings of Joana, I refer 
the reader to earlier publications [78, 65, 86]. 

In subsection 3.4.1, I describe the connection between information flow 
control and slicing that is exploited by Joana. After that, I go into some 
of the features of Java and describe some of the techniques that Joana 
applies in order to treat them appropriately. Specifically, subsection 3.4.2 
considers dynamic dispatch, subsection 3.4.3 looks at the challenges posed 
by exceptions and, lastly subsection 3.4.4 shows how objects are represented 
and handled by Joana. 

Note that I will not discuss concurrency in this chapter but in chapter 4, 
particularly in section 4.2. 


3.4.1 Slicing and Information Flow Control 


Slicing has a strong connection with non-interference and, hence, inform- 
ation flow. In the following, I give a cursory description of the intuition 
behind this connection. For my explanation, I use batch-job termination- 
insensitive non-interference (BTINI) [22] in a very simple setting. 

Consider a deterministic program P which defines and uses only two 
variables h,l. Variable h is thought of to contain secret values that are 
not supposed to influence the variable I, which is assumed to be publicly 
accessible. 

A suitable instantiation of BTINI then demands that 


Vo,0’ e2.oll) =o (DAP Lo APL => IPI) = IPI’) (N), 


where È is the set of all program states and P || o means that P terminates 
for initial state o. 

Now assume that there is a valid slice P” of P with respect to the value of I 
at the end of P that does not contain any use of h. Then it can be shown 
that P is non-interferent. A rough and intuitive argument for this goes as 
follows: Fix a valid slice P’ of P that does not contain any use of h and let 
0,0’ € È with o(l) = o’ (1) and assume that P |} o and P || o’. Since P’ is a 
valid slice of P with respect to the final value of 1, we can conclude that P’ 
also terminates on o and that the final state P’ (o) coincides with P(o) on I: 


P'o rP (oc) (1) = P(o) (I). 
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The same argument can be made for o’: 
F Y RP (P =P). 


Moreover, since (a) P’ does not contain any use of h and therefore only 
uses l itself and (b) o(1) = o’ (1), it must be P’ (o) (1) = P’ (o’) (1). Together, 
it follows that 


P(o) (0) = P (0) 0) = Po) (0) =P(0)(). 


For PDG-based slicing, this basic idea can be exploited to give formal proofs 
for the general case. Horwitz et al. [91] show that program dependence 
graphs adequately capture program execution behaviour. Extending this 
work, Reps et al. [140] show the Slicing Theorem that states that PDG-based 
program slices are indeed valid, i.e. that a program and its slices exhibit 
the same execution behavior with respect to the slicing criterion. 
Snelting, Robschink and Krinke apply the Slicing Theorem to argue that 
non-interference according to Goguen and Meseguer [71, 70] can be verified 
using PDGs and slicing [157]. 

Wasserrab [164] shows the correctness of PDG-based slicing and applies 
this result to show that slicing can be used to verify BTINI for sequential 
programs with multiple procedures. 

For concurrent programs, simple properties such as BTINI are not suffi- 
cient anymore. I will consider non-interference properties for concurrent 
programs in section 4.2. 


3.4.2 Dynamic Dispatch 


In subsubsection 3.2.1.2, I discussed how interprocedural control-flow 
graphs are built by constructing the control-flow graphs of each procedure 
and then connecting them appropriately. This works fine for simple 
languages in which all call targets can be resolved statically, that is at 
compile-time. 

Modern programming languages, however, usually support some form 
of late binding, i.e. that names are not resolved statically at compile-time 
but dynamically at run-time. In the context of procedures (which are also 
called methods in object-oriented languages), late binding is also known as 
dynamic dispatch: For a dynamically dispatched method, there may exist 
multiple implementations and in contrast to statically dispatched methods, 
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the actually executed implementation is not selected at compile-time but 
deferred to runtime. 

In Java, the programmer can declare classes and two types of methods: 
Static methods are associated with the class itself and therefore independent 
of any instances of this class. They are dispatched statically, that is calls of 
them are resolved at compile-time. 

The other type of methods are instance methods: They are associated with 
every instance of the class individually’. 

For instance methods, Java makes it possible to provide multiple imple- 
mentations through its class inheritance mechanism which allows methods 
to be overridden — that is, a sub-class can re-declare a method declared in its 
superclass and provide another implementation for it. 

For the call of an instance method, the bytecode only specifies the static call 
target, that is the call target which is derivable at compile-time from static 
type information. The method which is actually called is then resolved 
dynamically at run-time using the actual type of the receiver object. 

An example for this can be seen in Listing 3.1: The method call in line 25 is 
dispatched dynamically. The static call target is A: :f, however at runtime 
B: :f is called since the runtime type of parameter a is B. 

For a static analysis this means that method calls in general cannot be 
resolved uniquely at compile-time but must be approximated. In order for 
the static analysis to be sound, this has to be an over-approximation. The 
example Listing 3.1 also illustrates that it is crucial for a sound program 
analysis to capture all possible call targets of dynamically dispatched 
method calls. If it does not, it may miss important program behaviour: 
For example, Listing 3.1 contains an information leak: the secret value that 
is read in line 18 is printed to a public console in line 8. An information 
flow analysis that does not detect B: :f as possible call target for the call in 
line 25 would miss this illegal information flow. 

A static program analysis that aims for a safe over-approximation of the 
actual program behaviour must therefore in particular over-approximate 
the possible targets of every instance method call. 

Hence, in the interprocedural control-flow graph multiple outgoing call 
edges from the same call target are allowed. With the definition of 


9In Java there are also private methods which are only accessible from within the same 
class and therefore are also bound statically. But I ignore them here for simplicity. 
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1 class A { 

2 void f(int x) { 16 class Main { 

3 //do nothing 17 static void main() { 

4 } 18 int secret = readPIN(); 
5% 19 A a = new A(); 

6 class B extends A { 20 B b = new B(); 

7 void f(int x) { 21 run(secret, b); 

8 print(x); 22 run(secret, b); 

9 } 23 } 

10 } 24 static void run(int x, A a) { 
11 class C extends A { 25 a. f(x); 

12 void f(int x) { 26 } 

13 print(42); 27} 

14 } 

15 } 


Listing 3.1: An example which shows why dynamic dispatch must be handled 
correctly 


interprocedural control-flow graphs presented in Definition 3.2 on page 46, 
this is no problem: The correspondence relation ® discussed earlier relates 
call edges with return edges and not just nodes and, thus, also incorporates 
the call target in the identification of a call. 

There exist several program analysis techniques for the approximation 
of dynamically dispatched method calls that I will discuss briefly in the 
following paragraphs. Since Java allows that class loading is deferred to 
runtime, they all assume that all classes are available for static analysis. 
All of these techniques construct a directed graph, the call graph which 
reflects the calling structure of a given program. Its nodes correspond to 
the program’s procedures and there is an edge from p to p’ if p may call 
p’. Call graphs can be obtained both dynamically and statically. In this 
work, I only consider static call graphs and because of that I will omit the 
qualifier static from now on. 

The analysis techniques that I will describe mainly differ in their precision, 
that is, their ability to approximate the possible targets of a call as closely 
as possible. 
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Precise resolution of dynamic dispatch is an important and critical feature 
for any static analysis aimed at a language like Java and in particular for 
static information flow analysis tools like Joana. 

For one, the precision of dynamic dispatch resolution directly affects the 
precision of a static analysis: Suppose that the object b in line 22 is an 
instance of C instead of B. Then the program in Listing 3.1 would be secure 
because the secret is never printed. However, an analysis that fails to 
exclude B: :f as possible call target in line 25 is also not able to rule out the 
execution of line 8. 

Secondly, precise handling of dynamic dispatch is also important for 
scalability of a sound analysis: Consider a statement such as p.equals(q). 
Then a sound analysis has to assume that p may be an instance of any 
available class and that the call p.equals(q) resolves to every available 
implementation of equals — unless it is able to incorporate additional 
information about p. If such information is not exploited, the resulting call 
graph may be substantially bigger than necessary, practically prohibiting 
any further analysis for scalability reasons. 

Particularly, the applications of Joana that I present in chapter 4 (see e.g. 
section 4.3 or section 4.7) rely on precise handling of dynamic dispatch. 


Main::main Main::main Main::main 


Main::run 


(A::f | (B ) (Cf) 


(a) class hierarchy analysis (b) rapid type analysis (c) points-to analysis 


Figure 3.22: Call graphs for the program from Listing 3.1 resulting from the 
application of different analyses 


3.4.2.1 Class Hierarchy Analysis 


Perhaps the simplest non-trivial analysis for approximating dynamic 
dispatch is class hierarchy analysis (CHA) [52]. This analysis considers 
the inheritance relationships between classes and resolves a dynamically 
dispatched method call to the static call target c: :f to all methods D: :f 
such that D is a subclass of c that overrides method f. 
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Clearly, for class-based languages like Java, this rule is sound: If D' is an 
arbitrary class that is not a subclass of c, then no method D::f can be a 
valid call target for any call with static target C: :f. 

For the example in Listing 3.1, using CHA would resolve the call in line 
25 to the possible call targets A: :f, B::f and C::f. This results in the call 
graph depicted in Figure 3.22a. Note however that C::f is considered as a 
possible runtime call target even though C is never instantiated. 


3.4.2.2 Rapid Type Analysis 


Rapid Type Analysis (RTA) [23] is an improvement of CHA which addi- 
tionally takes instantiation into account: If c is a call site with static call 
target C::f and D is a subclass of C that implements f and is instantiated 
somewhere in the program, then D: :f is considered a possible call target 
for c. 

Implementations of RTA usually require a main entry point and use an 
iterative approach to compute the classes which are instantiated and the 
methods reachable according to the above rule. 

RTA is obviously still sound for languages like Java: D: :f cannot be called 
at runtime if D is never instantiated. Moreover, RTA always delivers a 
result that is at least as precise as CHA: If CHA does not consider D: :f as 
possible runtime call target, then neither does RTA. 

For the example in Listing 3.1, RTA finds out that C is not instantiated. 
Therefore, it resolves the call in line 25 to the possible call targets A: :f and 
B: :f, resulting in the call graph in Figure 3.22b. This shows that RTA can 
be more precise than CHA. 

However, RTA still cannot rule out the case that A::f is called since A is 
instantiated. 


3.4.2.3 Points-To Analysis 


Points-to analysis [16, 88, 158] is a general technique which aims to 
determine the possible runtime values of pointer variables. Among its 
numerous applications, points-to analysis can in particular be used to 
resolve static call targets [84]. 

Points-to analysis is concerned with the computation of points-to graphs, 
i.e. relations PT c P x J where P is a finite set of abstract pointers and J is 
a finite set of abstract instances. 
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For an abstract pointer p, 


PT) = til (p,i) € PT) 


is also called the points-to set of p. The commonly used intuitive meaning 
for o € PT(p) is that p may point to o at runtime or, conversely, the intuitive 
meaning of o € PT(p) is that p definitely does not point to o at runtime. 
This is specifically useful for call graph construction: in order to stay 
sound, one wants to rule out impossible call targets!”. 

With points-to information available, static call targets can be resolved as 
follows: Let c.f(01,...,0n) be a call site with static call target c::f. Then 
D: :f may be an actual runtime call target if c may point to a D object. This is 
still sound: If c definitely never points to any D object, then D: : f definitely 
is not a call target. Furthermore, points-to analysis always delivers a result 
which is at least as precise as the result of RTA: If D is not instantiated at 
all, then no reference can point to any D object. 

Lastly, for the example in Listing 3.1, points-to analysis can find out that 
ain line 25 does not point to any instance of runtime type A or C. Hence, 
it can rule out A::f and C::f as runtime call targets for the call in line 25. 
This results in the call graph depicted in Figure 3.22c. 

As I already mentioned, points-to analysis is a powerful analysis technique. 
Joana not only uses it to resolve dynamic dispatch but also for alias analysis. 
I will look at this more closely in subsection 3.4.4. 


3.4.3 Exceptions 


Exceptions are Java's mechanism and language construct for handling errors 
at runtime. If a program encounters an erroneous state or condition, it 
can throw an exception that can be caught at some other place to handle 
the error gracefully. In Java, there are two kinds of exceptions. Explicit 
exceptions have to be declared, thrown and caught explicitly. The other 
kind, implicit exceptions, are thrown by the Java runtime environment in 


10Note that the notion p may point to o at runtime does not say anything about whether this 
means “sometime at runtime” or whether this statement is bound to a specific point of the 
program. Further note that it not necessarily means that p actually will point to o at some 
point at runtime. It only means that it is not the case that p definitely does not point to o at 
runtime (bound to some specific point or not). 
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certain situations for which there is no sensible reaction. This includes 
environmental problems like memory shortage or input/output errors, but 
also the failure of single instructions because of programming errors. For 
example, a field access of the form a.x = y may fail because a is null, or an 
array access ali] = o may fail because i is out of the bounds of a. 

An overview of Java’s language constructs in connection with exceptions 
is given in Figure 3.23. 

From the point of view of a static information flow analysis, exceptions 
are challenging: On the one hand, they have to be properly dealt with in 
order to capture every possible program behavior. In particular, bytecode 
instructions like field or array accesses may cause exceptions that are not 
apparent from the program’s bytecode. Therefore, a static information flow 
analysis must model the behavior of these bytecode instructions carefully. 
On the other hand, exceptions have to be handled with sufficient precision 
in order to not introduce too much spurious control-flow which in turn 
may cause many false alarms [103]. Particularly, JoaNna’s precision is 
heavily affected by its handling of exceptions. For example, the successful 
verification of the case studies described in section 4.3 would not have 
been possible without precise exception handling. 

Like Joana’s exception analysis, I focus in the following on implicit 
exceptions that are caused by programming errors. 


int readFile(File f) void bar(File f) { 

throws IOException (1) { try { (4) 
if (!f.exists()) { int x = readFile(f); 

throw new IOException(); (2) } catch (IOException e) { 

} (5) 
oer } 

} println(foo()); (6) 

int foo() { } 


int[] arr = new int[5]; 


return arr[6]; (3) 


} 


Figure 3.23: Overview of exceptions in Java: checked exceptions have to be declared 
(1), thrown (2) and handled (4)/(5); unchecked exceptions are thrown 
implicitly by the JVM and do not have to be handled (3)/(6) 
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1 class A {int x;} 

2 void foo(Stringl] args) { 
3 int secret = inputPIN(); // HIGH access 
4 A benign = inputLOW(); 
5 A a = null; 

6 if (benign != null) { 

7 a = new A(); 

8 } 

9 if (secret < 9999) { 
10 a.x = 42; 
11 } 
12 print(@); // LOW output 
13 } 


(a) source code (b) control-flow graph 


Figure 3.24: Example for an information leak through exceptions 


_ _fentry) nn > data dep. 
A -==> control dep. 
OG LOW 


’, 


A 
-O 


Figure 3.25: program dependence graph for the example in Figure 3.24 — the 
path from the high access in line 3 to 12 is highlighted in bold 


Figure 3.24a shows an example for information flow that solely occurs 
because of implicit exceptions. The control-flow graph can be seen in 
Figure 3.24b and the program dependence graph in Figure 3.25. 

With the assumption that the return values of inputPIN and inputLow are 
not statically determinable, the program in Figure 3.24a has a control-flow 
graph like the one depicted in Figure 3.24b: In particular, this control-flow 
graph has a control-flow edge from line 10 to the exit node since the field 
access in line 10 may lead to a crash if a is null. If it fails, line 12 is not 
executed because the program crashes with a NullPointerException. This 
means that the value of secret influences whether line 12 is executed or 
not. 
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Consequently, the program dependence graph contains a control depend- 
ency from line 9 to line 12 that, together with the data dependency from 
line 3 to 9, constitutes a path from line 3 to line 12. 

The example in Figure 3.24 shows that exceptions can induce a significant 
amount of additional control-flow and, thus, additional control depend- 
encies. The control-flow from line 10 to the exit for example induces 
control-dependencies both from line 10 to 12 and from 9 to 12. If there 
were statements after line 12, then all these statements would also be 
control-dependent on both 9 and 10. 

However, assume that inputLOW is never null. Then a cannot be null and 
therefore the program cannot crash. If static analysis cannot prove that 
inputLOW is never null, then it will report a false alarm. Therefore it can 
be beneficial to perform additional analyses that enable to safely rule 
out control-flow due to exceptions, e.g. by proving that certain pointer 
variables cannot be null. 

Joana performs an analysis that rules out impossible null pointer excep- 
tions, both intraprocedurally and interprocedurally. Its capabilities are 
illustrated in Figure 3.26: 


e Since it is flow-sensitive with respect to a!=null, it finds out that the 
field access in line 10 is safe. 


e Moreover, it can detect that accesses such as the one in line 12 are 
safe because the pointer variable is guaranteed to be initialized. 


e It also is able to follow references passed as parameters to methods. 
In particular, it tracks whether any of them may be null. Hence, 
the analysis can find out that line 17 is safe. However, it is still 
conservative enough to detect that accesses such as line 18 is not safe. 


Details about Joana’s null pointer analysis can be found in the dissertation 
of Graf [78]. 

Apart from that, within the scope of the RS? project!!, we also integrated 
an analysis to rule out exceptions due to out-of-bounds array accesses. I 
will briefly go into that in section 4.3. 


J will introduce and explain RS? in chapter 4. 
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1 class A {int x;} 

2 void foo() { 

3 int benign = inputLOW(); 
4 A a = null; 

5 A b = new A(); 

6 if (benign > 1742) { 

7 

8 


a = new A(); 

} 
9 if (a != null) { 
10 a.x = 42; 
11 } 
12 b.x = 42; 
13 bar (b); 
14 baz(b) ; 
15 baz(null); 
16 } 
17 void bar(A a) {a.x = 42;} 
18 void baz(A x) {a.x = 42;} 


Figure 3.26: The capabilities of Joana’s null pointer analysis 


3.4.4 Objects 


For static information flow analysis, objects pose a number of challenges: 


e They usually have fields through which information can flow. An 
analysis that distinguishes between fields can be more precise than 
an analysis that does not. The ability to differentiate between two 
different fields of the same objects is also called field-sensitivity. 


e In Java, objects can be aliased which means that the same location 
in memory can be referenced by different access paths. Information 
flow analysis has to take aliasing into account in order to ensure that 
all information flows can be detected. 


Figure 3.27 shows two example that illustrate these challenges. In Fig- 
ure 3.27a we see a small program that stores high and low data within 
the same object, but in different fields. Hence, the print-statement in line 
8 does not reveal high data. Figure 3.27b shows why it is important to 
handle aliasing properly: The print statement in line 10 obviously leaks 
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the secret that was just stored in a1.x. Since after line 6, al and a3 refer to 
the same object, line 14 is illegal as well. In contrast, line 12 does not leak 
secret information since al and a2 refer to different objects and therefore 
line 8 does not influence the value of a2. x. 

Joana handles all the examples shown in Figure 3.27 properly by carefully 
incorporating objects into its PDG representation. The full details can be 
found in the dissertations of Hammer [86] and Graf [78]. 


3.4.4.1 Heap Dependencies 


Central to this approach is the notion of heap dependencies that can be 
defined with the help of points-to analysis. I have already explained the 
basic intuition behind points-to analysis in subsection 3.4.2 and will goa 
bit deeper into it in subsubsection 3.4.4.3. 

Heap dependencies can occur between statements that store to or read 
from the heap. A statement sz is called heap-dependent on a statement s1 
if s2 may use a heap location that sı may have defined. For example, a 


1 class A {int x;} 
2 void bar() { 
3 A al = new A(); 
4 A a2 = new A(); 
5 a2.x = ð; 
6 A a3 = al; 
1 class A {int x; int y} 7 int high = inputPIN(); 
2 void foo() { 8 al.x = high; 
3 A a = new A(); 9 int out! = al.x; 
4 a.y = ð; 10 print(out1); // ILLEGAL 
5 int high = inputPIN(); 11 int out2 = a2.x; 
6 a.x = high; 12 print(out2); // OK 
7 int low = a.y; 13 int out3 = a3.x; 
8 print(low); // OK 14 print(out3); // ILLEGAL 
9 } 15 } 
(a) fields (b) aliasing 


Figure 3.27: Two small example programs that illustrate aspects of objects that 
need to be handled properly by a static information flow analysis 
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statement y = a.f is heap-dependent on a statement b.g = z, if the fields f 
and g are the same and if a and b may point to the same object. 

For illustration, consider Figure 3.28 and Figure 3.29, respectively. 

Figure 3.28 shows the data dependency graph of the code example in 
Figure 3.27a. The statement low = a.y is heap-dependent on a.y = @ since 
the former reads from the same heap location that a.y = @ has written 
to. Also note that there is no heap dependency between the statements 
from a.x = high to low = a.y. Although they both access the object that is 
pointed to by a, they refer to different primitive fields within a. In Java, if 
an object has two fields of primitive type!? with different names, they are 
known to reside in different memory locations. 

Another example can be seen in Figure 3.29, which shows the data de- 
pendency graph of the code example in Figure 3.27b. 

This example shows three heap dependencies. Most notably, the statement 
out3 = a3.xisheap-dependent on a1.x = high. This is because the points-to 
sets of al and a3 coincide and therefore have a non-empty intersection. 
Hence, we conclude that a3.x in out3 = a3.x may refer to the same heap 
location as al.xin al.x = high. 

Note that the data dependency graphs in Figure 3.28 and Figure 3.29 
are simplified. In fact, Joana represents field access not only by a single 
node but by multiple nodes. Mainly this is done to be able to distinguish 
between different information flow caused by field accesses. For example, 
the operation that reads an object's field’s value from the heap is represented. 


(high = inputPIN()) 


x 


| 
dependency 
print (low) > data dependency 


- - - > heap dependency 


Figure 3.28: Data dependency graph of Figure 3.27a 


The term primitive type is used in Java for non-object types like int, double, char or 
boolean. 
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(high = inputPIN()) 


(a2 = new AQ) ... {al = new AQ a3 = al 
Ge aan 
. : 


7 -Aout = atx) __ (print (out3) 
print (out2) print(out1) > data dependency 


- -- > heap dependency 
Figure 3.29: Data dependency graph of Figure 3.27b 


by a structure as depicted in Figure 3.30. This structure consists of four 
nodes: One node for the actual instruction, two nodes for the base object 
and the field, respectively, and an additional artificial exit node. Such a 
representation makes it possible to distinguish between three kinds of 
information flow: For one, there are data dependencies from the base object 
and the field to the actual instruction (the instruction uses both the base 
object and the field to read its value). Secondly, a data-heap dependency to 
the field node represents information flow through the heap. And last but 
not least, the field access operation may fail because the base object is null. 


field-get (vl = v2.f) 


ı 
dd (v2) dh (f) 
= V2.hassae#i# CE sinasised § field A.f 
Fi dd a dd 
ce U 2 
` vl =v2.f 
exit dd (v1) 
cd’ “cd } 
> 4 


Figure 3.30: Joana’s PDG node structures corresponding to the operation that 
reads an object’s field’s value from the heap (taken from [78, Figure 
2.31]) 
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formal-in a actual-in a 


formal-out | _ 
field x 


1 void foo() { actual-out a 
De As field x 
3 bar(a); ; 
4 [high = inputPIN()] | 
ore 
5} : 
6 void bar(A a) { 
7 int high = inputPIN(); -> data dependency 
8 a.x = high; - - - > heap dependency 
9 } parameter structure 
parameter-in /-out 
(a) exemplified code snippet (b) relevant section of the PDG of the code ina 


Figure 3.31: How Joana incorporates objects into its parameter passing structures 


Only the base object and the exit node are involved in this exceptional 
information flow. 


3.4.4.2 Propagating Heap Access Across Procedures 


In order to also model field accesses across procedural boundaries, Joana 
incorporates them in the structures that represent interprocedural para- 
meter passing. For every method m, additional formal parameter nodes 
represent the field accesses performed by mor by any method called directly 
or indirectly by m. 

For this, Joana performs an interprocedural side-effect analysis: For each 
method, all its field accesses are collected and summarized as formal 
parameter nodes: Each of these additional parameter nodes represents 
read or write access to a set of heap locations. Moreover, Joana relates 
parameter nodes by parameter-structure edges: Roughly, parameter node 
p is connected to a parameter node p’, if p’ represents a field of p. More 
technically, parameter node p is connected to a parameter node p’ if the 
heap locations of p’ contain a field that can be obtained by dereferencing 
an object represented by p. 

Consider Figure 3.31 for a simple example: Method bar writes the field x of 
its parameter a. Hence, bar has a formal-out parameter node for the field 
a.x. This node is propagated to callers, so for each of a’s call sites, there is 
an actual-out parameter node corresponding to the formal-out parameter 
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node for a.x. The formal-in node for bar’s parameter a is connected to the 
formal-out node for a.x, since the latter represents accesses to the field x of 
a. 


3.4.4.3 Points-to Analysis 


For the remainder of this section, I take a closer look at points-to analysis, 
which is not only a tool for constructing precise call graphs but also a key 
ingredient for analyzing information flows across the heap. 

Points-to analysis as used by Joana is not a single, fully-determined 
analysis but rather a family of possible concrete points-to analyses where 
various aspects can be configured. Every choice has consequences with 
respect to the Joana’s precision and runtime performance. Hence, the 
choice of points-to analysis is important for practical applications of Joana 
and deserve explanation. Particularly, I will illustrate that for demanding 
analysis clients such as information flow analysis, there is no perfect choice 
of points-to analysis. 


Abstractions As I already mentioned in subsubsection 3.4.2.3, points-to 
analysis is concerned with the computation of points-to graphs, which 
are one-to-many relations between abstractions of pointer variables and 
abstraction of concrete object instances. These abstractions can be thought 
of as some kind of description generated from the static information 
available in the program’s code. 

Consider as an example Figure 3.32: Since n is a parameter, potentially 
infinite List objects are created in the loop. A common approach for 
points-to analyses is to represent all these objects by one abstract instance, 
described by something like “any instance of List that is instantiated in 
line 10”. Furthermore, the potentially infinitely many incarnations of the 
local pointer variable pr are represented by one abstract pointer variable, 
described by something like “the pointer variable pr at any point in the 
method List: :create”. 


Sensitivities Like all static analyses, points-to analyses are subject to 
several precision trade-offs. In the following, I look more closely at some 
of them. 
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class List { 5 class Foo { 

int d; 6 List create(int n) { 
7 
8 


1 
2 
3 List prev; List cur = null; 
4 


} for (int i = 0; i < n; i++) { 
9 List pr = cur; 
10 cur = new List(); 
11 cur.d = i; 
12 cur.prev = pr; 
13 } 
14 return cur; 
15 } 
16 } 


Figure 3.32: A code snippet that illustrates the abstractions in points-to analysis 


Flow-sensitivity Recall the general descriptions in section 3.1: A flow- 
sensitive points-to analysis takes into account the order of statements, 
whereas a flow-insensitive points-to analysis does not. Flow-insensitive 
points-to analyses usually compute one global points-to graph for the 
whole program, whereas flow-sensitive points-to analyses result in a 
separate points-to graph for each statement. 

Figure 3.33 shows an example which highlights the effect of flow-sensitivity 
in points-to analysis: We see two code snippets there which are identical 
up to statement order. Flow-insensitive points-to analysis computes the 
same points-to graphs for both of them, whereas flow-sensitive analysis 
results in different points-to graphs. 

Joana employs flow-insensitive points-to analysis. Some of the resulting 
precision loss is recovered by using Static single assignment form (SSA) [47, 
38, 42], an intermediate representation which is widely used in compilers 
and program analysis tools. Specifically, it is employed by WALA and 
Joana which is why I want to describe it briefly in the following. The 
key property of SSA form is that every variable is assigned to at most 
once. This simplifies some program analyses. For example, the reaching 
definitions analysis described before becomes simpler because definitions 
do not need to be deleted anymore. 

Every program can be transformed into SSA form. This transformation is 
usually performed on the given program’s control-flow graph. The idea 
is to introduce a separate copy for each definition of a variable. At join 
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a = new A(); a = new A(); 
b = new A(); b = new A(); 
a=b; c= a; 
c=a; a=b; 


A@1 (a) [Aer (a) —[Aa1 


A@2 (b ) A@2 
Q Q 


(c) (d) (e) 


N 
©) 


Figure 3.33: Two code snippets (upper part) and their points-to graphs (lower 
part) - c and d show the flow-sensitive points-to graphs at the end of 
the code in a and b, respectively. The points-graph in e results from 
flow-insensitive points-to analyses of both snippets. 


y3 = P(y1,y2) 
print(y3) 


Figure 3.34: Example showing a simple program and its SSA form 


points, where several control-flow paths meet, special statements called 
® functions have to be inserted. An easy example is given in Figure 3.34: 
The statement y3 = ®(yı, y2) means that yz is either yı or y2, depending 
on which control-flow path was taken before. Figure 3.35 shows the 
control-flow graph of the running example in SSA form. At node 9, three ® 
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statements!’ have to be inserted. For simplicity, I allow all these statements 
to be contained in the same basic block and assume that they are executed 
at the beginning of each loop iteration, just before the loop predicate is 
evaluated. 

Consider Figure 3.36 for an example of how SSA form can affect points-to 
precision. It shows the code snippets of Figure 3.33 in SSA form and their 
flow-insensitive points-to graphs. It can be seen that the points-to graphs 


entry 


Y 
9: is = ®li1,io) 
a3 = ©(a1,2) 
15: print(c3) b3 = ®(bı ,b>) 
c3 = ®(c1,c2) 
i3 <N 


Y 
exit 


Figure 3.35: The control-flow graph from Figure 3.3 in SSA form 


13T use the symbol ® here to be consistent with the literature. This is not to be confused 
with the correspondence function for interprocedural control-flow graphs. 
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differ and are almost the same as the flow-sensitive graphs depicted in 
Figure 3.33c and Figure 3.33d, respectively. Due to SSA form, it is made 
explicit which definition of a is used in the last two lines. Since there are 
two local variables for a now (one for each definition), there are also two 
points-to sets. 


Equality-Based vs. Subset-Based Another precision trade-off for 
points-to analyses is whether they are equality-based [159] or subset-based 
[16]. Equality-based points-to analyses do not take into account the 
direction of assignments, whereas subset-based points-to analyses do. 
An example for this can be found in Figure 3.37. The two code snippets 
only differ in whether b is assigned to a or vice versa. Since subset-based 
points-to analysis is sensitive to this difference, it produces two different 
points-to graphs, whereas equality-based points-to analysis produces the 


a; = new A(); a, = new A(); 
b = new A(); b = new A(); 
az = b; c= a; 
c = ag; ag = b; 


(a) (b) 


A@1 A@1 


A@2 A@2 


NU 


(c) (d) 


Figure 3.36: Effect of SSA form on flow-insensitive points-to analysis - The upper 
part shows the code snippets from Figure 3.33 in SSA form and the 
lower part the respective flow-insensitive points-to graph 
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same points-to graph for both snippets. Joana uses subset-based points-to 
analyses. 


a = new A(); a = new A(); 
b = new A(); b = new A(); 
a=b; b=a; 


(a) (b) 


A@1 (a)—Aa1 (a)—{Ae@1 
Oz A@2 A@2 (b }—[A@2 


(c) (d) (e) 


Figure 3.37: Subset-based (c, d) vs. equality-based (e) points-to analysis 


Context-Sensitivity Finally, I want to consider the effect of context- 

sensitivity on points-to analyses and their client analyses, specifically on 
the heap dependency graph construction performed by Joana. 
As already explained generally in section 3.1, a context-sensitive analysis 
not only analyzes the individual statements of a program but also takes 
into account their execution context!*. For points-to analyses, the execution 
context can include 


e (a finite portion of) the runtime stack just before the execution (k-CFA 
[155]) 


e the instance on which the method was called which contains the 
statement (object-sensitivity [125]) 


e the instance on which the method was called which contains the 
statement combined with the combination of the values of object- 
valued parameters (cartesian product algorithm(CPA) [8]) 


14Note that context-sensitive points-to analysis is usually not fully context-sensitive. This 
can be compared to the call string approach subsubsection 3.2.2.2 with limited stack depth. 


104 


3.4 Joana: PDG-based Information Flow Control for Java 


Usually, the context information is incorporated in the abstract descriptions 
of pointers. The kind of used context information can have a profound 
effect on client analyses, especially on Joana’s PDG construction algorithm. 


This is illustrated by the example programs in Figure 3.38. Both programs 
are secure, since the value they print is not affected by the secret input. 

Let us first consider Figure 3.38a in more detail. If Joana analyzes this 
program with context-insensitive analysis, it yields a heap dependency 
graph like depicted in Figure 3.39a. This is caused by the fact that (a) the 
points-to analysis performed by Joana is flow-insensitive, (b) after side- 
effect analysis is performed for each method, the same access summary is 
propagated to the callees without adapting it to the respective call site and 


1 class A { 1 class A { 

2 int x; 2 int x; 

3 3 void modify() { 

4 4 a.xtt; 

5 5,3 

6} 6} 

7 class CM1 { 7 class CM2 { 

8 void foo(int high) { 8 void foo(int high) { 

9 A al = new A(); // 01 9 A al = new A(); // 01 
10 al.x = high; 10 al.x = high; 

11 A a2 = new A(); // 02 11 A a2 = new A(); // 02 
12 a2.x = ð; 12 a2.x = Q; 

13 modify(al); 13 A a = random()>0.5?a1:a2; 
14 modify(a2); 14 a.modify(); 

15 int low = a2.x; 15 int low = a2.x; 

16 println(low) ; 16 println(low) ; 

17 3} 17 } 

18 void modify(A a) { 18 

19 a.xtt; 19 
20} 20 
21 } 21 


(a) (b) 


Figure 3.38: Two example programs showing the effect of context-sensitivity in 
points-to analysis on information flow analysis 


105 


3 Program Dependence Graphs for Object-Oriented Programs 
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Figure 3.39: Relevant section of the heap dependency graph of Figure 3.38a with 
different pointer analyses 


(c) with context-insensitive points-to analysis, the parameter a of method 
modify is described by the same abstract pointer, regardless of the call site. 
Since both o1 and o2 may be passed to modify, a may point to both of them. 
Hence, according to the points-to information, the field access in line 19 
may access both 01.x and 02.x. This information is propagated to both 
call sites of modify and, based on this information, Joana adds a heap 
dependency: one from line 10 to the actual-in node for a.x at the call in 
line 14 and one from the actual-out node for a.x at the call in line 13 to line 
15. This constitutes a PDG path from line 10 to 15. 

In contrast, such a mix-up does not occur when Joana analyzes the example 
with 1-CFA. Here, a heap dependency graph such as the one depicted 
in Figure 3.39b is obtained. The reason is that 1-CFA uses two different 
abstract pointers for the parameter a of modify, one for each call site. This 
way, both calls can be treated as if they called different methods, which 
each operate exclusively on 01 and 02, respectively. In effect, the access 
summaries become more precise, Joana does not add the spurious heap 
dependencies, so that line 10 and line 15 are not connected via heap 
dependencies. Note that object-sensitive points-to analysis yields the same 
result as context-insensitive points-to because modify is only called on one 
object. 

However, there are also examples where no k-CFA helps: Such an example 
is shown in Figure 3.38b. Again, this program is secure as it always prints 
@, regardless of the high value. 
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7 7al.x = high zn al.x = high 
l 

i a2.x = 0 a2.x = ð 
| 

| 

| 

| 

$ 
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xy 
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(01.x) | (01.x) (02.x) | (02.x) 
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(a) context-insensitive points-to (b) object-sensitive points-to 


x x 
(01.x,02.x) H (01.x,02.x) 


in out 


x 


Figure 3.40: Relevant section of the heap dependency graph of Figure 3.38b with 
different pointer analyses 


As the return value of random() cannot be statically determined, the points- 
to set of a contains both 01 and 02, with any points-to analysis. Hence both 
ol and o2 may be the receiver object of the call in line 14. Both context- 
insensitive points-to and k-CFA merge 01 and o2 into the points-to set of the 
this pointer in modify. In particular k-CFA uses only one abstract pointer 
for this, since modify only has one call site. This leads to multiple spurious 
heap dependencies and a false alarm, as can be seen in Figure 3.40a. 

In contrast, object-sensitive points-to analysis uses two different abstract 
pointers <o1, this> and <02, this> for this and can distinguish between the 
call on o1 and the call on 02. The points-to set of <o1,this> only contains o1 
and the points-to set of <o2, this> only contains <o2, this>. 

Technically, Joana treats 01: :modify and o2: :modify as two different meth- 
ods. Hence, it also computes two distinct access summaries that are 
both propagated to the only call site. In effect, Joana is able to keep the 
accesses on 01 and 02 separate. The heap dependency graph, which is 
shown in Figure 3.40b, does not contain the spurious heap dependencies 
of Figure 3.40a and hence also not the unnecessary heap dependency path. 
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13 class C { 

14 void foo(int high) { 

15 A al = new A(); // 01 

16 A a2 = new A(); // 02 

17 A a = random()>0.5?a1:a2; 
18 a. init (high); 

19 B b = a2.b; 


1 

2 Bb; 

3 void init(int x) { 
4 B b = new B(); 

5 // <ol::init, 03>, 
6 // <o2::init, 03> 
7 b.x = x; 

8 


9 3 SUS Aa b; 20 int low = b.x; 
21 print(low); 
10.3 2} 
11 class B{ 
; 23 
12 int x; 24 } 
13 } 


Figure 3.41: Effects of a context-sensitive heap model on Joana’s PDG construction 


Additional context information can not only improve the representation of 
abstract pointers, but also of abstract instances. A context-sensitive points- 
to analysis that incorporates the context information in its representation 
of abstract instances is said to employ a context-sensitive heap model. With a 
context-sensitive heap model, more instances can be distinguished, which 
again can be beneficial for client analyses like Joana’s PDG construction, 
especially when dealing with nested object structures. 

Consider the example in Figure 3.41. We assume that Joana uses object- 
sensitive points-to analysis with a context-sensitive heap model. Because 
of object-sensitive abstract pointers, the two possible calls of A::init in 
line 18 are treated as calls to two different methods, 01::init and 02: : init. 
This additional context information is used to split up the creation site of B 
in A::init. In o1::init, the local variable b points to <o1::init, 03> and in 
02: : init, it points to <o2::init, 03>. Hence the write accesses to b.x in line 
7 can be separated and Joana is able to conclude that the heap location 
accessed in line 20 does not contain high information. 

The examples I just presented not only show that context-sensitivity can 
have a positive effect on Joana’s precision but also that there is no perfect 
choice of points-to analysis. Indeed, Figure 3.38a is an example that 
profits from the use of 1-CFA, whereas with object-sensitive points-to, 
Joana reports a false alarm. In contrast, Joana can verify the security 
of Figure 3.38b only with object-sensitive points-to, whereas no k-CFA 
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provides enough context information to eliminate false alarms. Figure 3.41 
illustrates the same phenomenon for context-sensitive heap models: Joana 
does not report an illegal flow with object-sensitive points-to but no k-CFA 
is sufficient for that. With a slight variation of Figure 3.41, we yield an 
example analogous to Figure 3.38a whose security can be proven with 
1-CFA, while object-sensitivity has no positive effect in comparison to 
context-insensitive points-to. 


Performance Impact of Points-to Analysis The examples also give an 
idea of another important effect of the choice of points-to analysis, namely 
the effect on the runtime performance of Joana. In my explanation of the 
examples, I mentioned two important aspects of Joana’s modelling of 
objects and handling of points-to analysis: 


e Joana implements context-sensitivity in points-to analysis by treating 
a method with different contexts as two different methods. That is, if 
a method is analyzed in multiple points-to contexts, multiple copies 
of it occur in the call graph and in Joana’s PDG. 


e Joana performs an analysis of memory access for each method in each 
points-to context and propagates summaries of these field accesses 
from callee to caller, in order to construct the heap dependency graph. 
These summaries are not only propagated to the direct, but also to 
indirect callers. Hence, every procedure dependency graph contains 
information about every field access performed by one of its direct 
or indirect callers. 


These two aspects can cause a substantial amount of PDG nodes repres- 
enting field accesses, in particular at parameter nodes at call sites. For 
example, this may lead to a significant rise in the memory and runtime 
performance of summary edge computation. 

Therefore, the choice of the points-to analysis and how Joana incorpor- 
ates points-to information into its structures plays an important role for 
applications such as those presented in chapter 3. For example, the case 
study described in section 4.7 could only be verified with object-sensitive 
points-to, and the PDG construction times differed significantly between 
different choices of points-to analysis. I will discuss this in section 4.7. 
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Listen, do you want to know a secret? 
THE BEATLES 


Applications of Joana to 
Software Security 


In this chapter, I report on several applications of Joana within the scope 
of the Reliably Secure Software Systems priority program (RS?) that ran 
from 2010 to 2017 and was funded by the German Research Foundation 
(DFG). In particular, I will focus on the contributions of the programming 
paradigms group of Prof. Dr.-Ing Gregor Snelting at KIT. 

The chapter is organized as follows. In section 4.1 I give a general 
introduction into the RS? project and its motivations. After that, I describe 
various collaborations with other groups of RS?. These collaborations can 
be generally split into three categories: 


e RS? consisted of several sub-projects - the programming paradigms 
group was part of the sub-project Information Flow Control for mobile 
components. I describe this project and its contributions in section 4.2. 


e Within RS®, three reference scenarios were developed. They served 
as real-world examples where the several research groups who 
participated in RS? [3] could apply and combine their results. Our 
group participated in two of the three reference scenarios: 


- Insection 4.3, I describe the Security in E-Voting scenario [41] and 
how Joana was combined with an interactive theorem prover 
to prove certain cryptographic properties of a prototypical 
electronic voting system. 


- In section 4.4, I describe the reference scenario Software Security 
for Mobile Devices [20] and particularly how Joana was extended 
to show information flow properties of Android applications. 
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e In addition to such structural umbrellas like the reference scen- 
arios, RS? also fostered other collaborations of the several research 
groups that were part of it. Our group participated in four such 
collaborations: 


— We took part in the development of the RS? Information Flow Lan- 
guage (RIFL), a language that makes it possible to specify security 
requirements in a tool-independent, language-independent and 
machine-readable way. I describe RIFL and Joana’s support for 
it in section 4.5. 


- As an application of RIFL, several RS? research groups de- 
veloped ırspec, a benchmark suite for information flow security. 
Together with two other tools, Joana and its Android variant 
Joprow can be evaluated using ırspec. I go into the details of 
IFSPEC in section 4.6. 


- In section 4.7, I report on the SHRIFT approach, which shows 
how a static information flow control tool like Joana can be 
applied to improve the performance, precision and thus the 
usability of system-wide usage control. 


- Last but not least in section 4.8 I shortly report on a collaboration 
with the Application-oriented Formal Verification group at KIT that 
presents an approach to the modular security verification of 
component-based systems in which Joana was used to lower 
the burden for a first-order theorem prover. 


4.1 General Description and Motivation of RS? 


In this subsection, I give an overview over the motivation, goals and 
structure of the RS? priority program. This overview is based on the 
descriptions that were given on the website [6] of RS? and on excerpts of 
the program’s proposal, which also can be found on its website [4, 2]. 
The main thesis of RS? was that there is a need for complementing 
traditional approaches to IT security in order to give reliable security 
guarantees for complex software systems. 


RS? In classical IT security approaches, mechanisms like authentication, 
cryptographic protocols are used to ensure that only trusted entities (e.g. 
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programs) may perform actions ina given system. Trust is usually provided 
by some form of certificate that uses cryptographic signatures to prove the 
given entity’s identity and integrity. Additionally, access control ensures 
that a given entity may only perform allowed actions. 

Together, these techniques create a zone that is to a great extent protected 
from unknown and potentially malicious code. However, even with such 
a zone it remains unclear what guarantees can be given with respect to 
security. Once an entity has entered the trusted zone, it may perform 
all allowed actions. For example, it may combine these actions to do 
harm or to disclose information which are not supposed to be disclosed. 
In consequence, trust-based and mechanism-oriented approaches cannot 
protect from malicious entities that are falsely trusted. 

Therefore, such approaches need to be complemented by property-oriented 
solutions: Such solutions concentrate on (a) formalizing the security re- 
quirements of a given system in the form of properties and (b) providing 
methods for verifying that the given system enjoys these properties. 
Focusing on properties and their verification offers a number of advantages: 
Firstly, security properties can be rigorously analyzed (e.g. for contradic- 
tions). Moreover, precise and well-defined security guarantees can be 
given if a system can be rigorously shown to satisfy a given property. 
Therefore, the main goal of RS? was to develop concepts and techniques 
that enable trustworthy certification of system-wide, technical security 
requirements and which adequately respect the semantics of programs. 
In order to achieve this goal, RS? was driven by three guiding themes: 


1. the development of precisely defined security properties; such proper- 
ties enable to formalize and hence reason about security, requirements for 
a given system, just like it is common for functional requirements. 


2. the development of program analysis methods and tools for the verific- 
ation of security properties; ideally, these techniques are sound, scalable 
and usable, and 


3. the development of concepts for understanding and certifying security 
aspects in complex software systems. 
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4.2 The Sub-Project “Information Flow Control 
for Mobile Components” 


Information Flow Control For Mobile Components (IFC4MC) was a sub-project 
within RS? that comprised the programming paradigms group at KIT 
and the Software Construction and Verification group at the university of 
Miinster. 

I focus on the KIT side of the projects. From our point of view, IFC4MC 
was concerned with three main topics: 


1. information flow properties that are suitable for modern program 
structures like concurrent programs 


2. enforcement of these properties using program dependence graphs 
3. modularity of PDG-based program analyses 


In the following, I give an overview of the achievements in the first two 
items. The first two items were first tackled by Giffhorn [65, 66]. The third 
item is considered in detail in the dissertation of Graf [78]. 


4.2.1 Information Flow Properties for Concurrent 
Programs 


The security properties that we were mainly concerned with are non- 
interference-like. Generally, non-interference-like properties demand that 
high input does not influence low-observable program behavior. For 
sequential and deterministic batch-like programs, this essentially means 
that if the program is applied to two states that only differ in high variables, 
the result states also only differ in high variables. 

However, this is insufficient for advanced programming language features 
like concurrency. In contrast to sequential programs, concurrent, or multi- 
threaded programs are composed of multiple threads, sub-programs that run 
simultaneously and may or may not be executed on multiple processors. 
A scheduler periodically distributes threads to the available processors. 
Consequently, if no particular scheduler is assumed, concurrent programs 
have to be considered as non-deterministic in the sense that a given input 
may lead to multiple possible program behaviors. This has to be accounted 
for when designing appropriate security properties. 
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Figure 4.1a and Figure 4.1b show examples that illustrate different types 
of possible information leaks in concurrent programs. 

Figure 4.1a contains one simple explicit (A) and one simple implicit (B) 
leak. These two types of information flow also can occur in sequential 
programs. The example also contains a third leak (C) that can also be 
considered an explicit information flow but crosses thread borders: It may 
occur since statement (D) may be executed by thread t1 before the main 
threads executes statement (C). 

Another type of leak is shown in Figure 4.1b. This example neither contains 
an explicit nor an implicit information leak. However, there are two output 
statements which may be observed by a low attacker and whose execution 
order may reveal something about high data: Observe that t2 is delayed 
by a loop whose execution time directly depends on the high input pin. 
Hence, if we assume a scheduler that after each step chooses the next active 
thread by fair dice roll, then the larger the pin is, the more likely it is that 
t1 executes its output statement before t2 does. 

The notion that captures such considerations is probabilistic non-interference. 
The idea here is to consider the probability distribution of possible program 
behaviors. Probabilistic non-interference then demands that if two inputs 


main: iain: 
in = input(HIGH ; 
an er Spent 


pin = input (HIGH) 


output(LOW, 42 * pin + 17) (A) while (pin > 0) { 


if (pin > 2) { 


output(LOW, pin) (B) ; pin-- 
} 
spawn t2 
output(LOW, x) (C) N 
tl: g , 
x = pin (D) t2: output(LOW, 1) 


(a) (b) 


Figure 4.1: Examples for different types of leaks that can occur in concurrent 
programs: a shows explicit information flows within (A) and across 
(C,D) thread borders and an implicit information flow (B); b shows a 
truly probabilistic leak: the larger the value of pin the more likely it is 
that @ is output before 1 
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only differ in high parts, then the probabilities of the resulting low- 
observable program behavior is the same. 

Let Tr be the set of program behaviors, also called traces, and I the set 
of inputs. A trace can be thought of to be a sequence of operations that 
accurately describes what a program does and how the memory contents 
develop. Some operations are used for input and output. We assume that 
input and output operations (also called input events and output events, 
respectively) use different channels for high and low observers. 

An input i € I leads to multiple possible traces t € Tr(i) € Tr. Each of these 
traces has an occurrence probability!> P;(t). 

An attacker does not see the full trace but only its so-called low-observable 
part. This is modeled by a function Ez : Tr > Tr that strips off the parts of 
a trace that cannot be observed by a low attacker, like output events on 
high channels or high parts of the memory. 

The attacker also only sees some part of the input, namely those input 
events that operate on the low channel. To model this, we overload Ez to 
Er :1— I that strips off high parts of inputs. 

Hence, if program F is run with input i and exhibits program behavior 
t, then a low observer only sees the low part i, = Ez (i) of that input and 
observes that P exhibits t; = Er (t). From this, they can conclude that the 
input must have been some 7’ € Ee (iL) and that some t’ € Beh) must 
have been executed. 

Now, probabilistic non-interference aims to ensure that the attacker cannot 
learn anything from that. The argument goes as follows: Assume that 
the attacker knows the probabilities P; (E7! (t,)) for all i’ € Ee (ip) and 
also assume that these probabilities differ. In other words, there are 
ig, 1 € Er (iL) with P;, (E. (tL)) > Pi, (E7! (tL)). Then the attacker could 
conclude that it is more likely that the full input is ig than ij. In order 
to deprive the attacker of this possibility, probabilistic non-interference 
demands that P; (E7! (t)) = Pi, (E7' (tr) for all i, i) € E7" (ir). 

The example in Figure 4.1b clearly violates probabilistic non-interference: 
The attacker may conclude from the low output 01 that the pin was 
probably large and from 10 that it was probably small. 


15In general, P; assigns probabilities to sets of traces. We assume a countable set of traces, 
hence all P; are discrete probability distributions so that P; is fully specified by specifying it 
for single traces. 
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main: 
spawn t1 
spawn t2 
pin = input(HIGH) 
main: while (pin > Q) { 
spawn t1 pin-- 
spawn t2 } 
t1: output(LOW, 2) t1: output(LOW, ®) 
t2: output(LOW, 1) t2: output(LOW, 1) 


(a) (b) 


Figure 4.2: a: An example which passes Giffhorn’s criterion but not LSOD — b: 
Giffhorn’s criterion allows access to high input before the first low- 
observable non-determinism occurs 


Probabilistic non-interference is in general hard to verify directly as it 
requires to know probability distributions of traces which is why Giffhorn 
also considered sufficient criteria for it. One such criterion is low-security 
observational determinism (LSOD) [169], which essentially demands that a 
program only has one low-observable low-behavior for a given low-part 
of the input. If LSOD holds, then the probability distributions become 
very simple and probabilistic non-interference can be easily verified. 
Central to LSOD is the observation that non-determinism manifests itself 
in the form of conflicts. Two operations form a conflict if they may be 
executed in multiple orders. For instance, if two statements sı and sz are 
composed concurrently then the scheduler may decide to run either of 
them first so that both the execution orders s1, S2 and s,s, are possible. 
Apart from the absence of explicit and implicit leaks, LSOD also demands 
that there is no conflict of low-observable events. For instance, the example 
Figure 4.1b is clearly rejected by LSOD since it contains two conflicting 
low-output statements. 

One particularly pleasant property of LSOD is that it is scheduler- 
independent. This means that no assumptions on the scheduler are necessary 
for probabilistic non-interference to hold. Therefore, a respective security 
certificate can be re-used when changing the environment. 

In his dissertation [65], Giffhorn showed that LSOD can be checked using 
program dependence graphs. 


117 


4 Applications of Joana to Software Security 


start 


influence of high input 
« 
allowed 


no influence > common dynamic 
of high in- ancestor of m and n 
u 
put allowed 
mM +------- > n 


low observable 
conflict 


Figure 4.3: Idea of the RLSOD improvement 


However, LSOD is also very restrictive: It essentially forbids any low- 
observable non-determinism, which is often the very motivation for 
designing a system in a concurrent way in the first place. So, even a 
program that does not access high data, like the one in Figure 4.2a, violates 
LSOD if it contains conflicts. 

This is why Giffhorn also proposed a slight improvement on LSOD. His 
idea was to allow conflicts if they are not influenced by high data. One 
example of this can be seen in Figure 4.2b. 

In later work [40, 31], we took this as a starting point for improvements on 
LSOD. The central idea here was to push the “influence sphere” of high 
events on conflicts even further into the direction of conflicts. We observed 
that, under some assumptions about the scheduler, more conflicts can be 
considered benign. Key to this observation is the notion of common dynamic 
ancestors (cda): For two statements m,n, a statement c is called common 
dynamic ancestor of m and n if (a) c is a dominator for m and n, i.e. if every 
control-flow path to m or n must traverse c first and (b) if c is guaranteed 
to never execute concurrently to m and n. Hence, a common dynamic 
ancestor of m and n is any point in the program which is guaranteed to be 
executed before m and n. 

Now the idea of RLSOD, which is sketched in Figure 4.3, is as follows: If c 
is a common dynamic ancestor of two conflicting statements m and n, any 
statement s that is guaranteed to be executed before c can only delay both 
m and n but cannot determine in which order m and n are executed. Hence 
s can safely be allowed to be influenced by high input. Consequently, it 
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main: 
pin = input (HIGH) 
while (pin > Q) { 
pin-- 
} 
spawn t1 
spawn t2 
tl: output(LOW, ®) 
t2: output(LOW, 1) 


Listing 4.1: An example which passes RLSOD but not Giffhorn’s criterion 


suffices to check that no statement s that lies on some control-flow path 
between c and m or c and n may be influenced by high input. 

As an example, consider the program in Listing 4.1: It contains a low- 
observable conflict after high data is accessed, hence it is rejected by 
Giffhorn’s criterion. However, this high access is guaranteed to execute 
before t1 is spawned - a point in the program that is a common dynamic 
ancestor of the two output statements. Such high access is allowed by 
RLSOD and hence the conflict can be considered benign. As we showed in 
Bischof et al. [31], this consideration works with every common dynamic 
ancestor. Indeed, the RLSOD check can be specified with respect to a 
function cda which assigns every two statements m,n acommon dynamic 
ancestor. The closer cda(m,n) is to m and n, the larger the portion of the 
program on which influence of high input is allowed can be and, hence, 
the more precise the check becomes. 

An imprecise yet safe choice is to always use the start point of the program 
as cda. With this choice of the cda function, the RLSOD check becomes 
essentially Giffhorn’s criterion. 


4.2.2 Modeling and Analyzing Concurrency in Program 
Dependence Graphs 

Basically, PDGs for multi-threaded programs can be obtained by com- 

puting a PDG for each thread and connecting these sub-PDGs using 


interference edges, an additional kind of edge that captures inter-thread data 
dependencies. 


119 


4 Applications of Joana to Software Security 


entry main 
z T 3 


Pa Y Da 
pin = input(HIGH)| [spawn tl] [pin > 0] 


-` N 


BEN 47 x 
output(LOW,pin) output(LOW,x) 


entry t1 
T 


eines » data dep. 


x= pin -- -> control dep. 


— interference dep. 


Figure 4.4: PDG of Figure 4.1a with interference edges 


To illustrate this kind of dependency, consider again Figure 4.1a. The 
information leak in statement (C) occurs because statement (D) may be 
executed before statement (C) and therefore the high value pin is first 
written into the variable x and then output to a low channel. This is a 
special kind of data dependency that crosses thread borders and is called 
interference dependency. The PDG of Figure 4.1a can be found in Figure 4.4. 
As defined formally by Giffhorn [65, Definition 3.8], statement sz is interfe- 
rence-dependent on s4, if s2 may use a value which sı computes and sı and 
s2 may happen in parallel. Two statements sı and sz may happen in parallel if 
it is both possible that sı is scheduled before sz and that s2 is scheduled 
before s4. 

Due to decidability reasons, may-happen-in-parallel information must 
be approximated. To yield a sound analysis, this approximation is con- 
servative in the sense that the statically computed relation MHP has the 


property: 
s1 and s2 may happen in parallel = MHP(s1,52) 


That is, if ~MHP(s,,s2), then only one execution order of sı and sz is 
allowed. Conversely, however, it may be the case that MHP(s1, s2) holds 
even though sı and sz can only occur in one particular execution order. 
In his dissertation [65], Giffhorn describes a fairly sophisticated MHP 
analysis that takes into account (a) definite execution orders that can be 
inferred from the program’s control-flow and (b) thread creation and 
joining. 


120 


4.3 Reference Scenario “Security in E-Voting” 


This MHP analysis can be further improved by also taking concurrency 
control mechanisms like locks into account: 

For example, in Java one can use synchronization on objects’ monitors, a 
simple locking mechanism to achieve mutual exclusion, to ensure that for 
critical sections one thread at a time can be active. Threads that are about 
to enter such a critical section while another thread is active have to wait 
until the active thread is finished. This way, the possible interleavings can 
be restricted. 

A MHP analysis that takes into account locking will consider less statements 
to run in unspecified order and hence be more precise. 

One static analysis formalism which can model concurrency and in partic- 
ular locks is dynamic push-down networks (DPNs) [37, 118]. Roughly, DPNs 
represent programs with multiple threads by a series of call stacks and are 
able to model dynamic thread creation, unbounded recursion and finite 
abstractions of thread-local and procedure-local state. Moreover, using tree 
automata techniques, DPNs can be used to check whether a multi-threaded 
program has lock-sensitive executions with given properties [63], like MHP 
information. Furthermore, by iterated analysis [131], DPNs can also be 
used to compute interference dependencies directly. 

We combined DPNs and PDGs to remove interferences which in fact do 
not occur due to locking [80]. This is especially beneficial in situations 
where locking is actually used to impose definite execution orders. 


4.3 Reference Scenario “Security in E-Voting” 


In this section, I describe the reference scenario Security in E-Voting. This 
description is based on various RS? publications [5, 41, 115]. First, I give 
a short motivation. After that, I give an overview of the contributions of 
the reference scenario overall and the contributions of the programming 
paradigms group in particular. 


4.3.1 Motivation 


In recent years, more and more elections are conducted electronically. 
This includes national and municipal elections, as well as elections within 
associations, societies, and companies. There are two main categories of 
such systems: The first kind consists of electronic voting machines like 
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recording electronic voting systems and scanners that are usually installed 
in polling stations. The other kind is remote electronic voting systems that 
are used by voters to vote over the internet using their own devices like 
desktop computers or smart-phones. 

Since elections are a critical part of democracies, it is crucial that they are 
held in a way that satisfies some basic properties. Two such properties are: 


Privacy The system ensures that the voters’ votes remain confidential. 


Verifiability Voters have the possibility to check that their choices have 
been properly counted. 


In traditional elections, these properties are usually sufficiently ensured 
by providing voting booths that are not observable from outside or by 
making the counting public. 

E-voting systems also aim for such properties and ideally, the developers 
of E-Voting systems can be presumed to be benevolent. However, it is also 
true that E-Voting systems are complex hardware and software systems 
and as in all such systems programming errors can hardly be avoided. 
Verification techniques and procedures are therefore used to ensure that 
these systems enjoy particular security properties. 

In this reference scenario, we consider the verification of privacy properties 
of Java programs that use cryptographic operations, where the final aim is 
to provide strong cryptographic guarantees on the code of a fully fledged 
remote e-voting system which is designed to provide confidentiality of the 
votes. 


4.3.2 CVJ Framework 


As a first step, Küsters, Truderung Graf and Scapin proposed the CV] 
framework for the cryptographic analysis of Java programs that use crypto- 
graphic primitives [116, 114]. This framework enables existing tools that 
can check non-interference properties for Java programs, but a priori cannot 
deal with cryptography, to establish cryptographic indistinguishability 
properties at the code level. 

The CVJ framework combines techniques from program analysis and 
universal composability [43, 134, 113], a well-established concept in cryp- 
tography. CVJ works in two steps. The idea of the first step, which is 
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Figure 4.5: Visualization of the general approach employed to verify the security 
of the E-Voting system [115, Figure 1] 


illustrated on the left side of Figure 4.5, is to check non-interference prop- 
erties for the Java program to be analyzed where cryptographic operations 
such as encryption are performed within so-called ideal functionalities. 

A given Java program P,eq1 (the box on the left in Figure 4.5) that uses real 
cryptographic primitives is transformed into a Java program Pigoq) (the 
box in the middle of Figure 4.5), where the real cryptographic primitives 
are replaced by idealized primitives. These idealized primitives provide 
guarantees in face of unbounded adversaries and can often be formulated 
without probabilistic operations. Therefore, they can be analyzed by 
tools that cannot deal with security notions specific to cryptography 
(probabilities, polynomially bounded adversaries). The results of the 
CVJ framework imply that if Pidea] is non-interferent, then the original 
Java program Peq (using actual cryptographic operations) enjoys strong 
cryptographic indistinguishability. 

In addition to the reduction of a cryptographic verification task to an 
ordinary non-interference check, the CVJ framework also consists of a 
second step that is illustrated on the right side of Figure 4.5 and tackles 
the problem that the systems to be analyzed are often open: They interact, 
for example, with an untrusted (and unspecified) network. Analysis tools 
such as Joana however can only deal with closed Java programs, in this 
case the combination of the open system with one particular environment. 
Therefore, the CVJ framework also provides a proof technique that en- 
ables program analysis tools to verify non-interference properties of open 
systems. Such an open system is non-interferent if the combination of 
this system with any environment (which is closed) is non-interferent in 
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Figure 4.6: Visualization of the hybrid approach 


the ordinary sense. According to the CVJ framework, it is not necessary 
to check ordinary non-interference for all environments, rather it suffices 
to establish non-interference for a carefully designed family of environ- 
ments. These environments only differ in their inputs, so that they can be 
expressed as one parameterized environment (see box on right-hand side 
of Figure 4.5). 

Graf [78] shows that this works in particular for PDG-based tools such as 
JOANA. 


4.3.3 The Hybrid Approach 


In summary, the CVJ framework in principle enables a static analysis tool 
that can verify unrestricted non-interference to perform cryptographic 
analyses on programs using cryptographic primitives. However, an 
automatic tool like Joana cannot be sound and completely precise at the 
same time. Joana in particular may report false alarms, i.e. falsely reject a 
program which is actually non-interferent. 

To remedy this, Küsters et al. propose the hybrid approach [115], which 
combines the strengths of automatic information-flow analysis tools with 
the strengths of interactive theorem provers. This was joint work of the 
groups of Kiisters, Snelting and Beckert, to which I contributed the Joana 
part of the verification of the case study. In our work [115], we demonstrate 
the hybrid approach on a case study, a small prototypical e-voting system. 
In this case study, we combined Joana with KeY [11], a theorem-prover 
for Java. 
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Figure 4.6 illustrates how the hybrid approach works: The task is to verify 
non-interference of a given (Java-like) program and we assume that the 
security of this program as-is cannot be verified using a given automatic 
tool. The hybrid approach now works in two steps: 


1. Additional code is added to the program which makes explicit to the 
automatic tool that the falsely reported illegal flow is in fact not present. 


2. It is shown that the modifications of step 1 satisfy the requirements for 
a conservative extension. Apart from certain syntactical restrictions, this 
means that the essential behavior of the program has not been changed by 
the modification. This boils down to verifying a functional property of the 
given program, a task that can be performed using an interactive theorem 
prover. 


For reference, I cite the definitions of extensions and conservativity here. 


Definition 4.1 (Extension [115, Definition 1]). Let P = P(x] be a deterministic 
and closed (Jinja+!°) program. An extension of P is a program P’ = P’ {x 
obtained from P in the following way. First, a new component M is added to P 
consisting of some number of classes with the following properties: 


(i) the methods and fields of the classes in M are static, 
(ii) the arguments and the results of the methods of M are of primitive types, 


(iii) the methods of M do not refer to classes defined in P (in particular, no methods 
and fields of P are used in M), 


(iv) all potential exceptions are caught inside M, 
(v) all methods of M always terminate. 


Second, P is extended by adding statements of the following form in arbitrary 
places within methods of P: 


16Jinja [105] is a java-like programming language which is equipped with a formal 
semantics to make it accessible for reasoning with a theorem prover. Jinja+ [116] extends 
Jinja by various features which are useful in the context of the CVJ framework. 
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(a) (output to M) 


(4.1) C.f (e1,...,€n) 


where C is a class in M with a (static) method f and eı,...,en are expressions 
without side effects. 


(b) (input from M) 
(4.2) r=C.fl(e,...,en), 


where C is a class in M, C.f is a (static) method with some (primitive) return 
type T, €1,...,€n are expressions as above, and r is an expression that evaluates 
without side effects to a reference of type t. (Such an expression can, for example, 
be a variable or an expression of the form o.x, where o is an object with field x.) 


Definition 4.2 (Conservative extension [115, Definition 2]). An extension 
P’ [x] of PX] is called a conservative extension of P[x], if for all initial values @ 
of high variables x the following is true in the run of P’ [A]: Whenever a statement 
of the form (4.2) is executed, it does not change the value of r. That is, the value of 
r right before the execution of the assignment coincides with the value returned 
by the method call C.f(e1,...,€n). As such, statement (4.2) is redundant. 


Consider the example in Listing 4.2. We assume the security policy that 
the initial value of secret must not influence the final value of pub and that 
bar does not violate this policy. Then the program is secure: Although 
secret is added to the result of the method foo in line 12, it actually has 
no influence on it. This is because line 12 is only executed if secret==0, 
but has no effect in this case. However, a static information flow tool like 
Joana reports an illegal flow because it does not reason about values and 
assumes that the final value of b (and therefore the final value of pub) may 
be influenced by the initial value of secret. Now consider Listing 4.3. Here, 
the program from Listing 4.2 has been modified in such a way that Joana 
is able to verify non-interference: The value of b is saved (line 12) before it 
is possibly incremented (line 13) and overwritten afterwards (line line 14). 
Using a local killing definitions analysis [78], Joana is able to detect that b 
is indeed overwritten in line 14 and can correctly verify that the modified 
program is secure. According to the hybrid approach, it remains to be 
shown that Listing 4.3 is a conservative extension of Listing 4.2. It is easy 
to see that Listing 4.3 is an extension of Listing 4.2. It remains to be shown 
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1 class Example { 

2 static public int pub; 

3 static private int a; 

4 public static void main(int secret) { 
5 a= 42; 

6 bar (secret); 

7 int b = foo(secret); 

8 pub = b; 

9 } 

10 static int foo(int secret) { 
11 int b = a; 

12 if (secret==0) bt=secret; 
13 return b; 

14 3} 

15 static void bar(int secret) { 


. ee 
18 } 


Listing 4.2: A secure program for which Joana reports a false alarm (adapted from 
[115], p. 309) 


that this extension is indeed conservative. This boils down to proving that 
in line 14 the value returned by M.get() equals the value of b just before 
the execution of line 14. This can be done for example with an interactive 
theorem prover like KeY. 


4.3.4 Case Study: E-Voting Machine 


Within the scope of our work [115], we demonstrated the hybrid approach 
on a small prototypical e-voting machine, using Joana as automatic in- 
formation flow control tool and KeY as a theorem prover for the subsequent 
proof of conservativity. 

We extended the program conservatively and proved a non-interference 
property with Joana (and the CVJ framework). The size of the conservative 
extension was 934 lines of code (LoC). The non-interference property that 
Joana had to verify essentially says that the voters’ choices have no 
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1 class Example { 

2 static public int pub; 

3 static private int a; 

4 public static void main(int secret) { 
5 a = 42; 

6 bar(secret); 

7 int b = foo(secret); 

8 pub = b; 

9 =} 

10 static int foo(int secret) { 
11 int b = a; 

12 M.set(b) ; 


13 if (secret==0) b+=secret; 

14 b = M.get(); 

15 return b; 

16 } 

17 static void bar(int secret) { 

18 ike 

19 4 

20 } 

21 class M { 

22 static int x; 

23 public static void set(int n) { x=n; } 
24 public static int get() { return x; } 
25 } 


Listing 4.3: An extension of the program in Listing 4.2 which makes the absence of 
illegal information flow explicit 


influence to the low output of the system!”. Joana could verify non- 
interference of this program in about 18 seconds on a standard laptop 
(Core i5 2.5GHz, 8GB RAM). To conduct the analysis, we wrote a small 
driver program (about 60 LoC) which sets various configuration options 
of Joana, initiates the PDG construction, identifies and annotates the 
appropriate nodes in the PDG, and triggers the information flow analysis. 


17Eor full details, I refer the interested reader to the original article [115]. 
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Apart from the adaptions to obtain the conservative extension, the further 
small adaptions of the e-voting machine were necessary for Joana to verify 
the system. In the following, I want to elaborate a bit on these adaptions. 


1 for( int i=0; i<N; ++i ) { 

2  switch( actions[i] ) { 

3 case ®: // next voter votes 

4 if (voterNr<numberOfVoters) { 
5 int choice = secret ? choices@[voterNr]:choices1[voterNr]; 
6 vm. collectBallot(choice) ; 

7 ++voterNr; 

8 } 

9 break; 

10 ita 

11 } 


Listing 4.4: A code snippet from the case study of [115] which needed to be adapted 


Listing 4.4 shows a critical code snippet from the case study which needed 
to be changed. The code is responsible for selecting a series of votes 
according to a secret bit. It processes two arrays of votes and, depending 
on secret, one of these arrays is chosen to be the array of votes that is 
processed subsequently. 

The problem for Joana is that it does not reason about values or array 
bounds. As a consequence, it must assume that voterNr may be out of the 
bounds of the arrays choices@ and choices1. This means that both branches 
of the statement in line 5 may throw an ArrayIndexOutOfBoundsException. 
Hence, all the program’s statements after line 5 are control-dependent on 
both branches of 5. 

Furthermore, both branches are control-dependent on the secret bit. As 
a consequence, every statement which is executed after line 5, including 
public outputs, is dependent on secret, so that Joana is not able to prove 
any reasonable non-interference property. 

However, the code snippet could be modified as shown in Listing 4.5. 
Here, both possible choices are loaded from the two arrays in lines 5 and 6 
before the actual decision is made in line 7. 

Since we assume a single-threaded environment, neither choices® nor 
choices! can change after lines 5/6, so that the code snippet in Listing 4.5 
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1 for(int i=0; i<N; ++i ) { 

2  switch( actions[i] ) { 

3 case 0: // next voter votes 

4 if (voterNr<numberOfVoters) { 

5 int choice® = choices@[voterNr]; 
6 int choicel = choices1[voterNr]; 
7 int choice = secret ? choice® : choicel; 
8 vm.collectBallot(choice); 

9 ++voterNr; 

10 } 

11 break; 

12 Bead 

13 } 

14 } 


Listing 4.5: A code snippet from Listing 4.4 with a small but critical modification 


is equivalent to the one in Listing 4.4. Moreover, the fatal chain of 
dependencies described before is prevented: Lines 5 and 6 may still throw 
an ArrayIndexOutOfBoundsException but this is independent of secret. Plus, 
line 7 does not throw any exception. 

Listing 4.6 shows another critical code snippet that needed to be ad- 
apted. The method is called only with valid values of votersChoice, 
i.e. with values between ð and numberOfCandidates - 1, where the field 
numberOfCandidates coincides with votersForCandidates. length. Formally, 
an exception is thrown if votersChoice is outside the desired range, but this 
actually never happens for this program. Consequently, since votersChoice 
is within the bounds of votesForCandidates, the array access succeeds. 
For Joana, there are two problems here. Firstly, whether the exception 
is thrown depends on the value votersChoice. This is a problem since 


1 public int collectBallot(int votersChoice) throws InvalidVote { 
2 if ( votersChoice < @ || votersChoice >= numberOfCandidates ) { 
3 throw new InvalidVote(); 

4 } 

5 votesForCandidates[votersChoice]++; 


6 } 
Listing 4.6: Another critical code snippet from the E-Voting Machine case study 


130 


4.3 Reference Scenario “Security in E-Voting” 


votersChoice depends on the secret bit and Joana does not know here that 
votersChoice is actually within bounds. Hence, as before, the program may 
possibly crash dependent on the secret bit, which precludes any sensible 
non-interference property. The other problem is very similar: Joana 
assumes that the array access may fail and since votersChoice is considered 
secret, Joana must assume that the program may crash depending on the 
secret value. 

Our solutions to these problems were 


1. remove lines 2 and 3; and 


2. surround line 5 with a try. .catch-block (with empty catch clause) which 
catches all Throwables, which effectively suppresses all possible exceptions 
which may occur there. 


It remained to show that the method indeed never throws any exception if 
called with valid values of votersChoice. This was done during the KeY 
proof phase. 

Apart from the two code snippets that I just discussed there were also 
others which prevented Joana from showing the desired non-interference 
property because of possibly invalid array accesses. This motivated us 
to introduce a simple array analysis into the WALA framework!®. This 
analysis was implemented by a student researcher under my supervision. 
It is based on the ABCD analysis by Bodik et al. [34] and can prove 
at least for simple cases that array accesses are valid and that a crash 
cannot happen!’. It was integrated into WALA in 2016 [69] and Joana 
can be configured to use it. Examples of what the analysis can and cannot 
recognize can be found on Github [67, 68]. 


4.3.5 Spec Slicing 


Within the scope of the case study, we observed in the KeY proof part 
that there are situations in which a given KeY specification only covers a 
small part of the program or, in other words, significant parts of the given 


181n section 3.4, I mentioned that Joana makes heavy use of WALA for analyzing Java 
bytecode. 

Note that due to time constraints the analysis could not be applied to the E-Voting 
reference scenario. 
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program are irrelevant to the specification. KeY specifications tend to be 
very complex and detailed and their proof may require a considerable 
amount of manual interaction. This motivated us to develop a method to 
decrease the amount of proof work that needs to be performed. 
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Figure 4.7: Visualization of spec slicing 


We devised a general technique which we call spec slicing [41]. The idea 
behind spec slicing is illustrated in Figure 4.7: If parts of the program do 
not influence the final state with respect to the proof obligation, they can 
be safely removed and functional verification can be performed on the 
simpler program. 

Verification of this simpler program can then be performed without any 
loss of precision but with possibly much less effort. The identification and 
removal of irrelevant program parts can be performed by an automatic 
tool like Joana. We already applied this technique to the E-Voting machine 
mentioned above: Parts of its implementation perform mere logging, which 
does not affect the voting result and therefore does not have any influence 
on the overall functional property which had to be verified. Using Joana, 
we gained a simpler but equivalent program without logging, which 
we verified using KeY to establish functional correctness for the whole 
program. 
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4.4 Reference Scenario “Software Security for 
Mobile Devices” 


The programming paradigms group also participated in the RS? Reference 
Scenario “Software Security for Mobile Devices” (SSMD). The goal of 
this reference scenario was to develop an app store that offers apps with 
security guarantees. The reference scenario combined several security 
techniques developed in the scope of RS?, including static analysis with 
PDGs and type systems, secure modeling and runtime enforcement. In 
the following, I describe the context of the reference scenario and its main 
result, the RS? certifying app store. After that, I focus on the contributions 
of the programming paradigms group. In the scope of this scenario, we 
developed Joproıp, an extension of Joana with support for the specialties 
of Android apps. I will describe the specifics of Joprorp and will elaborate 
on the challenges which have already been addressed and also on the 
challenges which remain open until this point. 


4.4.1 Motivation 


In today’s world, smartphones and other mobile devices are ubiquitous. 
They are used to store and process a wide variety of personal and sensitive 
data, including contacts, location, financial and health information and 
hence can be considered security-critical infrastructure. 

The most commonly used mobile operating system is Android, with a 
market share of 86.6% at the end of 2019 [1] and currently over 2.8 million 
apps in its app store [18]. The Android ecosystem offers a number of 
security mechanisms, such as sandboxing of applications and a permission 
system restricting access to critical resources. Moreover, applications 
available on Google Play” are scanned to detect malicious behavior. At 
the same time, Android still has problems with security violations [162] 
These commonly take the form of the application revealing the user’s 
sensitive information [133] or behaving in a way that is unexpected and 
harmful to the user [150]. 


20 Google Play is Android’s native app store. 
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This suggests that the security mechanisms employed in the Android 
ecosystem are not sufficient for enabling security-aware end users of 
Android devices to reliably enforce their personal security requirements. 
The RS? reference scenario “Software Security for Mobile Devices” aimed 
to offer a solution to these security problems by proposing an app store 
that provides user-definable security guarantees by integrating several of 
static and dynamic program analysis and security enforcement techniques. 


4.4.2 The RS? Certifying App Store 


The artifact of the SSMD scenario was the RS? certifying app store. Its 
architecture is shown in Figure 4.8. Basically, it follows a client-server 
architecture. 


app store server mobile device 


client app Ñ 


app browser | 


ar [ app distribution | 


| static analysis | 


policy editor | 


| instrumentation | verifier | 


Figure 4.8: Architecture of the RS? certifying app store [20, Fig. 1] 


The client consists of an app store app that the user can use to download the 
Android applications, configure information flow policies (see Figure 4.9a) 
and run and view the results of various information flow analyses (see 
Figure 4.9b). 

The app store integrates the different approaches of the various groups 
which contributed to the reference scenario. These approaches range from 
static analyses like PDGs and slicing or type systems to dynamic analyses 
combined with runtime enforcement. 

Joana, or more specifically its Android variant Joprom, is integrated in 
the server component: The user can specify an information flow policy 
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and send an analysis request to the server. The server then computes the 
app’s PDG and checks whether the given flow policy can be verified by 
using a PDG-based o check. The internal format of the specification 
is largely similar to the RS? information flow language that I will consider in 
section 4.5. There, I will also explain how Joana can be used to verify such 
policies. 
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Figure 4.9: Screenshots from the client-side app store app of the RS? certifying app 
store (compare [120, Figure 1(b), Figure 1(d)] and [20, Figure 2]) 


4.4.3 Joproip: Joana for Android 


In the following, I describe JopRrorp, an extension of Joana to support 
Android apps. The following text is largely based on an earlier publica- 
tion[123]. The initial version of JopRro has been implemented within the 
scope a diploma thesis under the supervision of our group [33]. 

The goal of extending Joana to handle Android apps poses several chal- 
lenges. Among these challenges are the following: 
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1. Although Android apps are developed in Java, they are not compiled 
to Java bytecode but to Android’s own Datvix bytecode. 


2. Standard Java applications use a single entry point (main), but Android 
apps have a multitude of possible entry points which are triggered by the 
Android system throughout the execution of the app 


3. Android apps employ intents, a message-passing mechanism to ex- 
change data and start external apps’ components, which requires to also 
analyze information flows between apps. 


These challenges are not specific to Android. For example, many Java 
applications with graphical user interfaces (GUI) also have multiple entry 
points which handle user input. However, different frameworks require 
different models specifying how these entry-points are used and Joana 
has no naturally built-in mechanism to specify such models*!. Similar 
considerations can be made for intents: intents are comparable to other 
message-passing mechanisms which are commonly found in client-server- 
applications but currently Joana does not provide a general mechanism 
which applies to a wide variety of message-passing mechanisms. We 
therefore consider our work on extending Joana to Android as a starting 
point to addressing these more general challenges. 

In the following, I present the work we have already done to address the 
challenges just sketched. In section subsubsection 4.4.3.1, I give a short 
overview of architectural aspects of Android apps, in subsubsection 4.4.3.2, 
I outline how we address the above mentioned challenges. After that, I 
conclude in subsubsection 4.4.3.3 by giving an outlook on future work. 


4.4.3.1 Overview of Android Applications 


In the following, I briefly discuss the architecture of Android applications. 
This overview is largely based on Android’s API documentation [72]. 
An Android application usually consists of multiple, loosely coupled 
components. In the simplest case, these components can either be Activities, 
Broadcast Receivers, Services or Content Providers. I now give a quick 
summary of what these components do and which roles they play. 


21This problem has been tackled in a bachelor’s thesis under my supervision [19]. 
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Figure 4.10: Illustration of how an implicit intent is delivered through the Android 
system to start another activity (see [73, Figure 1]); The sending activity 
[1] passes an action description, the Android system [2] selects an 
appropriate receiver component and starts it [3]. 


e Activities: An activity is an application component that provides a 
screen with which users can interact in order to do something. Each 
activity is given a window in which to draw its user interface. 


e Broadcast Receivers: A broadcast receiver responds to system-wide 
broadcast announcements. Many broadcasts originate from the 
system, but can also be initiated by arbitrary app components. 
Broadcast receivers do not display a user interface. Typically, a 
broadcast receiver is just a "gateway" to other components and is 
intended to do a very minimal amount of work. For instance, it 
might initiate a service to perform some work based on the event. 


e Services: A service runs in the background to perform long-running 
operations or to perform work for remote processes. It does not 
provide a user interface. Another component, such as an activity, 
can start the service and let it run or bind to it in order to interact 
with it, using a special kind of inter-process communication. 


e Content Providers: Content providers manage access to a structured 
set of data. They encapsulate the data, and provide mechanisms for 
defining data security. Content providers are the standard interface 
that connects data in one process with code running in another 
process. 


Android components use intents to exchange messages with each other. 
In particular, intents are used to start components. Intents can be explicit 
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Figure 4.11: Overview of the architecture of Joana 


or implicit. Explicit intents specify a receiver, whereas implicit intents 
leave it up to the Android system and/or the user to resolve their receiver. 
Figure 4.10 (taken from Android’s API documentation [73]) shows how 
Android processes an implicit intent. 


4.4.3.2 Approach 


In this section, I explain how we address the challenges I mentioned in 
subsection 4.4.3. 

Datvix front-end Figure 4.11 shows the general architecture of Joana. As 
can be seen in Figure 4.11, the PDG builder of Joana only depends on 
WALA’s analysis results and hence is decoupled from WALA’s front-end. 
As a consequence, we only needed to adapt WALA’s front end to be able 
to process Android apps. For this, we integrated the WALA front end code 
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of SCanDroid [62], a security analysis tool which is also based on WALA. 
This was a first step to extend Joana to handle also Android apps. 

Life cycle modelling. Classic Java applications have a single entry point 
and every execution of the application starts with an invocation of this 
method. Clearly, this assumption is not met by Android apps: As we 
already mentioned, Android apps have multiple callbacks, which may 
be triggered by the user or the Android system as a reaction to certain 
events. However, the order and the way these callbacks are triggered is 
not arbitrary, but follows certain rules. More specifically, the components 
of an Android app are driven by their life cycles. The life cycle of an activity 
can be seen in Figure 4.12. 
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Figure 4.12: Lifecycle of an activity (see [74, Figure 1]) 


It is not an option to run a separate analysis for each entry point, since 
there may be information flows which only occur if multiple callbacks 
are executed in sequence. Listing 4.7 (adapted version of a sample from 
DroidBench [61]) presents an example. 
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1 public class MyActivity extends Activity { 
2 static String addr = 

3 "http://www. google.de/search?q="; 

4 void onCreate(Bundle savedInstanceState) { 
5 telephonyManager = (TelephonyManager) 
6 

7 

8 


getSystemService( 
Context. TELEPHONY_SERVICE 

); 
9 /xx retrieve secret data of telephone (source) */ 
10 imei = telephonyManager.getDeviceld(); 
11 /xx extend request by secret data */ 
12 addr = URL.concat (imei); 
13 3} 


14 void onStart() { 
15 super.onStart(); 


16 try{ 

17 url = new URL(addr); 

18 conn = (HttpURLConnection) url 

19 .openConnection(); 
20 conn. setRequestMethod("GET”) ; 

21 conn. setDoInput (true) ; 

22 /*x send request to network (sink) */ 
23 conn.connect(); 

24 } catch(Exception ex){} 

25 } 

26 } 


Listing 4.7: Example for an information flow across entry points 


When onCreate() is executed, line 10 reads the IMEI of the phone and later, 
upon the invocation of onStart(), line 23 sends the IMEI to a server on 
the internet. However, such an information flow would not be detected 
if onStart() and onCreate() were each analyzed in isolation, since neither 
calls the other but both are called by the Android framework. 

To cover such flows as well, our approach synthesizes an entry method 
that simulates the Android framework by invoking all callbacks of the 


given app. 
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1 public class MyActivity extends Activity { 

2 static String URL= 

3 "http://www. google.de/search?q="; 
4 void onCreate(Bundle savedInstanceState){ 
5 san 

6 conn.connect(); 

7 

8 } 

9 void onStart() { 

10 ae 

11 imei = telephonyManager.getDeviceld(); 
12 URL = URL.concat (imei) ; 

13 } 

14 } 


Listing 4.8: An example in which there is no information flow between entry points 


In order to lose not too much precision, we take the life cycles of the app’s 
components into account. Consider again Figure 4.12: When onCreate() 
is called, either the activity has just been launched, or the app’s process 
has been destroyed and re-created. In either case, onCreate() is called on a 
fresh heap which cannot have been influenced by any other of the activity’s 
entry points. Thus, it is safe to assume that none of the activity’s entry 
points is called before onCreate. An example of how this assumption can 
be exploited to rule out impossible information flows and thus leads to 
increased precision is shown in Listing 4.8: In this variant of Listing 4.7, 
the source is contained in onStart() and the sink is contained in onCreate(). 
Since onCreate is never executed after onStart, the sink cannot be influenced 
by the source. 


Intents. Our model also provides basic support for intents. 

In order to incorporate the intents an application may react to, the ap- 
plication’s manifest is inspected, the possible intent targets are resolved 
and appropriate method calls are inserted into the artificial entry method. 
Similarly, our approach handles intents which may be issued during the ex- 
ecution of the application and whose target can be resolved to a component 
within the same application. Listing 4.9 shows an example of an activity 
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ShareActivity which declares the kinds of intents that it reacts to. It does 
so by using an intent filter. An intent filter specifies a set of possible intents 
an activity may react to. There are three aspects that can be used to specify 
intents: actions, categories and data. For example, in Listing 4.9 the activity 
ShareActivity can react to intents which specify android. intent. action. SEND 
as action, belong to the category android. intent.category.DEFAULT and send 
data of type text/plain. Note that in general, an intent filter may declare 
multiple action, category and data items. If an intent filter declares multiple 
action items, it matches all intents that match at least one of the declared 
action items. The same rule applies to categories and data. In Listing 4.10, 
we see exemplary code which issues an intent matching the intent filter 
depicted in Listing 4.9. Joprorp handles such code in the following way: 
It analyzes the app’s manifest and records for each activity the possible 
intents it may react to. 

Now suppose that during call graph construction, a piece of code like 
Listing 4.10 is encountered. JopRorp then inspects the object passed as 
parameter in the call in line 9. If the action can be resolved statically and 
matches the intent filter of a given activity, the call is interpreted as a call 
to the onCreate method of that activity. 

This analysis can be improved by a static approximation of strings. Such 
an approximation was implemented in the scope of a bachelor’s thesis 
under my supervision [167] and can be integrated into Joprorp. 


<activity android:name="ShareActivity”> 
<intent-filter> 
<action android:name="android.intent.action.SEND"/> 
<category 
android: name="android.intent.category.DEFAULT”/> 
<data android:mimeType="text/plain"/> 
</intent-filter> 
</activity> 
Listing 4.9: An exemplary section of an app’s manifest where a component declares 
that it reacts to certain intents — taken and adapted from the Android 
documentation [73] 
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1 public void foo() { 

2 Intent s = new Intent(); 

3 s.setAction(Intent.ACTION_SEND) ; 

4 s.putExtra(Intent.EXTRA_TEXT, "secret”); 

5 s.setType("text/plain”) ; 

6 // Verify that the intent will resolve to an 
7 //activity 

8 if (s.resolveActivity(getPackageManager()) != null) { 
9  startActivity(s); 

10 } 

11 } 


Listing 4.10: Example of how to invoke an activity using an implicit intent - taken 
and adapted from [73] 


4.4.3.3 Limitations and Future Work 


Now, I elaborate on the work that is left to do. 

At the moment, Joproıp cannot handle callbacks of graphical user in- 
terfaces. The graphical user interfaces of Android apps are typically 
described in separate files and these files also reference the callbacks which 
are invoked on user input, e.g. when a button is pressed. 

Hence, to also cover GUI callbacks, they have to be extracted from the 
separate files and integrated into the artificial main method appropriately. 
Another current limitation is that Joprorp only analyzes information flows 
inside single apps, but no information flows between different apps. 
This could be achieved by simply analyzing all the apps simultaneously. 
However, such an analysis would have to be re-done each time an app is 
added. Additionally, the analysis would have to be adapted in order not 
to assume that all the apps under analysis share a single heap (normally, 
different apps run in different virtual machines and hence have separate 
heaps). 

An alternative, more modular approach is outlined in Figure 4.13: First, 
the intra-app flows in each single application are analyzed and summaries 
are generated from these analysis results. After that, a communication graph 
is built by connecting one app’s summary with another app’s summary if 
one of the former app’s components may trigger one of the latter app’s 
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components by issuing an intent. The paths of such a graph represent the 
possible information flows between the apps. 


4.5 RIFL 


In this section, I report on RIFL (“RS? Information Flow Language”) [57, 
25], a joint effort of multiple researchers within the RS? project. The 
goal was to develop a language in which security requirements can be 
expressed. One main design goal for RIFL was to be tool-independent, i.e. 
not be tailored to a specific information-flow analysis. Tool-independence 
enables to create case studies that are suitable for multiple tools, so that 
multiple tools can be evaluated, compared and possibly even combined. 
As a consequence of its tool-independence, RIFL is a semi-formal language: 
It has a formally defined syntax with a specific intuition behind it, but no 
fixed security semantics. 

In the following, I describe the syntax of RIFL and the intended meaning 
of a RIFL specification. For this, I will base on the technical report on RIFL 
1.1 [25], to which I also contributed. Furthermore, I will report on Joana’s 


system channel application communication system channel 
read write 


= intra-application flow 


inter-application flow 


system-channel flow 


Figure 4.13: Possible approach to capture inter-app flows 
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support for RIFL and in particular will describe how a RIFL specification 
maps to an information flow query for Joana. 

As an application of RIFL, we also developed a benchmark suite for 
information flow analysis tools. I will describe this benchmark suite and 
some results from it in section 4.6. 


4.5.1 Description of RIFL 


In this subsection, I describe the syntax of RIFL and shed some light on 
the intended meanings behind it. To keep the description brief, I will 
refrain from showing the syntax explicitly but rather show examples on 
which I explain the different elements. For further information, I refer the 
interested reader to the technical report on RIFL 1.1 [25], which contains 
all details. 

Intuitively, a security requirement specification describes the allowed 
information flows within a program. Such a description usually consists of 


e information sources / sinks, i.e. locations at which the program imports 
/ exports information, 


e a set of domains together with a flow relation that specifies between 
which domains information is allowed to flow, and 


e adomain assignment which maps each source and sink to a domain. 


A RIFL specification roughly consists of these ingredients. The syntax of 
RIFL is XML-based and a Document Type Definition (DTD) is provided. 
In order to enable re-use, RIFL is separated into a language-independent 
part, which can be re-used for each concrete supported programming 
language and a language-dependent part, which provides the respective 
specifics for the supported languages. Currently,< the supported languages 
are Java Source Code (JSC), Java Bytecode (JBC) and Datvix Bytecode (DBC). 
Joana and its Android-variant JopRo1D support both Java Bytecode and 
Datvik Bytecode. In my descriptions, I will focus on Java Bytecode. The 
DBC front-end is syntactically identical to JBC and the JSC front-end only 
differs in the notation of method and field signatures. 

In the following, I will describe the different parts of a RIFL specification. 
This description is based on the technical report on RIFL 1.1 [25]. 
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4.5.1.1 Interface Specification 


The interface specification declares where a program imports and exports 
information. It specifies where in the program code a program reads input 
from the environment (sources) and where it provides output (sinks) to the 
environment. 


environment 


Figure 4.14: RIFL’s program model 


RIFL also provides a grouping mechanism. Sources and sinks can be 
grouped into categories and categories can be organized in a hierarchy: 
Categories may either contain sources or sinks or further categories. 

A rough sketch of RIFL’s program model can be seen in Figure 4.14. A 
program is basically regarded as a black-box which interacts with its 
environment (for example, the operating system) through a well-defined 
interface. This interface can be used to get data from outside (source) or 
provide output to the environment (sink). A RIFL specification describes 
exactly the parts of the environment which are used as sources and sinks 
for the program. 

An interface specification consists of multiple assignables. An assignable 
has an identifier which is called a handle and contains either a source, a sink 
or a category. The sources and sinks themselves are language-dependent 
since they refer to explicit locations in the program’s code and are explained 
later. A category has an identifier, its name, and may contain arbitrarily 
many sources, sinks or further categories. 
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It may appear redundant to have identifiers both for assignables and 
categories. But this has the simple reason that an assignable may consist 
of a single source or sink. Sources and sinks themselves do not have an 
identifier. Instead, their containing assignable provides one through its 
handle. The identifiers of categories and assignables are important since 
they are used for referring from other parts of a RIFL specification. 


Figure 4.15 shows the logical structure of an exemplary interface specifica- 
tion. The corresponding RIFL representation can be found Listing 4.11. The 
sources and sinks in this example are simplified. Their concrete structure 
will be discussed later. 

The specification declares the three handles fileshandle, HTTPhandle 
and HTTPShandle. HTTPhandle and HTTPShandle each consist of one 
sink (sendViaHTTP and sendViaHTTPS, respectively). The third handle 
fileshandle consists of the single category files which contains one 
bare sink storeToTmpFile and two sub-categories file-sources and 
file-sinks, in which the source loadFromFile and the sink storeToFile 


are located. 
fileshandle 


files 


storeToTmpFile file-sinks file-sources 


storeTofile > loadFromFile 


HTTPShandle HTTPhandle 


sendViaHTTPS sendViaHTTP 


Figure 4.15: Logical structure of an exemplary interface specification — the actual 
RIFL specification snippet can be found in Listing 4.11 — handles are 
represented by octagons, categories by rectangles and sources/sinks 
by ovals 


locationhandle 


getNetworkLocation 
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<interfacespec> 
<assignable handle="locationhandle”> 
<category name="location”> 
<source name="getGPS” /> 
<source name="getNetworkLocation” /> 
</category> 
</assignable> 
<assignable handle="fileshandle"> 
<category name="files”> 
<category name="file-sources"> 
<source name="loadFromFile”/> 
</category> 
<category name="file-sinks”> 
<sink name="storeToFile” /> 
</category> 
<sink name="storeToTmpFile”/> 
</category> 
</assignable> 
<assignable handle="HTTPhandle”> 
<sink name="sendViaHTTP” /> 
</assignable> 
<assignable handle="HTTPShandle"> 
<sink name="sendViaHTTPS” /> 
</assignable> 
</interfacespec> 


Listing 4.11: RIFL representation of the exemplary interface specification from 
Figure 4.15 


4.5.1.2 Security Domains and Flow Relation. 


As usual in the information-flow world, RIFL uses security domains to 
model different levels of confidentiality. A flow relation ~> C D x D over the 
set D of security domains is used to describe the allowed flows. Formally, 
a flow between security domains d and dz is allowed according to the 
given RIFL specification iff dy ~ dp. 

In RIFL, both the security domains and the flow relation are specified by 
declaring mere lists. RIFL aims to make as much explicit as possible. All 
pairs of domains which are related via ~ have to be listed explicitly. All 
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domains occurring in the flow relation have to be declared in the <domain>- 
section. The only implicit assumption made about the flow relation is that 
it is reflexive. Consequently, transitive relations like lattices may lead to a 
considerable rise of verbosity in a RIFL specification. 

The specifications shown in Listing 4.12 describe a diamond lattice: On the 
left-hand side, four security domains are declared, whereas the right-hand 
side specifies the diamond lattice structure on them. 


<domains> <flowrelation> 
<domain name="low” /> <flow from="low” to="mid1"/> 
<domain name="mid1”" /> <flow from="low” to="mid2"/> 
<domain name="mid2" /> <flow from="low” to="high”/> 
<domain name="high” /> <flow from="mid1" to="high”/> 
</domains> <flow from="mid2" to="high”/> 
</flowrelation> 


Listing 4.12: Specification of security domains and a flow relation in RIFL 


Since RIFL makes the implicit assumption that the specified flow relation 
is reflexive, declarations such as 


<flow from="low” to="low"/> 
need not be declared. However, it is neccessary to declare 
<flow from="low" to="high"/> 


since flow relations in RIFL do not need to be transitive. 


4.5.1.3 Escape Hatches. 


For the sake of completeness, I mention here that RIFL also supports a 
form of declassification [144], namely what-declassification. This is realized 
by the usage of escape hatches [143]. An escape hatch specifies that certain 
information may be declassified to a given security domain. 

Joana also supports a kind of declassification, where-declassification [87]. 
It does however not support the what-declassification mechanism imple- 
mented by RIFL. Joana does not reject a RIFL specification containing 
escape hatches, it rather ignores the escape hatches and hence treats such 
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a specification as if they were not there. Consequently, it checks the 
compliance of the given program with a stricter policy, which does not 
hurt soundness. 

For details on how escape hatches work in RIFL, I refer the interested 
reader to the technical report of RIFL 1.1 [25]. 


4.5.1.4 Domain Assignment. 


RIFL’s domainassignment describes a mapping of the declared sources 
and sinks to the declared security domains. It employs the handles of 
declared assignables to refer to the sources and sinks declared within that 
assignable. In particular, if the assignable contains a category, then all 
sources and sinks declared within that category (directly or indirectly) are 
referred to by the handle of the assignable. 

Listing 4.13 shows an example for a domain assignment, assuming the flow 
relation from Listing 4.12 and the interface specification of Listing 4.11. 
The third assign declaration refers to the assignable with the handle 
fileshandle and hence assigns the security domain low to all sources and 
sinks contained in fileshandle, namely storeToTmpFile, storeToFile and 
loadFromFile. 


<domainassignment> 
<assign handle="locationhandle” domain="high” /> 
<assign handle="HTTPShandle” domain="high” /> 
<assign handle="fileshandle” domain="low” /> 
<assign handle="HTTPhandle” domain="low” /> 
</domainassignment> 


Listing 4.13: Exemplary domain assignment in RIFL 


4.5.1.5 Sources and Sinks 


Sources and sinks in RIFL are language-specific, i.e. which kinds of sources 
and sinks are available and the concrete syntax depend on the concrete 
programming language. In RIFL, there are specializations for Java Source 
Code, Java Bytecode and Datvix Bytecode. In the following, I will focus 
on Java and Datvik Bytecode since the JBC and the JSC front-ends of 
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RIFL support the same kinds of sources and sinks and only differ in the 
syntax of method and field identifiers. Note that the Java Bytecode and 
Datvik Bytecode front-ends are syntactically identical, therefore I will only 
consider the Java Bytecode front-end. 


4.5.1.6 Method Parameters and Return Values. 


In Figure 4.16, we see two views on Java methods that may be employed 
when thinking about their role in specifying sources and sinks. 


information passed to 
information passed from outside via parameters 
outside via parameters 


actual parameters 


formal parameters are sinks 


are sources 


environment 
method called 


application 
method called 


from environment 


return value 
\s sink) 


from application 


return value 
is source 


information passed to . 
outside via return value information passed to 
outside via return value 


Figure 4.16: Two views on methods 


On the left, we see an internal view. This is the view which is used for 
application-internal methods which are called from the environment. 
Examples for this include the main method of a simple Java application 
or any callback of an Android app. When such an application-internal 
method is called from the environment, its parameters can be used to pass 
information from the environment to the application. In other words, using 
the intuitions of RIFL, any parameter of an application-internal method can 
be considered a source. Conversely, when the application-internal method 
finishes, it passes its return value to the environment. In other words, the 
return value of an application-internal method can be considered a sink. 

On the right-hand side of Figure 4.16, we see the external view on a method. 
This view is to be employed for external environment methods which are 
called from the application. Examples for such usage of library methods 
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include writing into or reading from files. Here, the application uses the 
parameters of the external methods to pass information to the environment 
(for example, the next line of text to be written) and the return value to 
import information from the environment (the next line from a text file). 
Since both views are valid in their respective context, method parameters 
and return values can be both specified as sources and sinks. Table 4.1 
summarizes the different usages of method parameters and return values 
as sources and sinks. 


source sink 

application method | parameters return value 
called from outside 
call of environment | return value | parameters 
method 


Table 4.1: Method parameters and return values as sources or sinks 


4.5.1.7 Heap Locations. 


A Java application may exchange information with the environment not 
only through method parameters and return values but also through the 
heap. RIFL supports the specification of the following kinds of heap 
locations: 


Object fields / static fields Fields of objects and static fields can be spe- 
cified both as sources and sinks. The specification of an object field is to 
be understood in an object-insensitive way. That means that if the object 
field f of the class C is specified as a source, then o. f is considered a source 
for all instances o of class C. Static fields are specified in the same way as 
object fields. 


Content and length of arrays Arrays are treated like objects with two 
special fields content and length. That is, it is possible to e.g. specify the 
contents of every int[] array as source or sink. 


Fields of objects received as parameters of methods If an applica- 
tion method receives its parameters from the outside through a parameter 
of non-primitive type (i.e. an object), it may be unsuitable to treat the 
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parameter itself as a source since it may only be a reference to heap loc- 
ations which contain the actual information. Therefore, RIFL provides 
the possibility to not only specify parameters but also reachable fields as 
sources. Note that, until version 1.1, RIFL does not allow to specify fields 
reachable from parameters of external method calls or from return values 
of internal or external methods. 


4.5.1.8 Exceptions. 


In Java, exceptions constitute an implicit channel of information. This 
especially applies to the communication between an application and its 
environment through internal or external methods. Therefore, RIFL makes 
it possible to specify exceptions as sources and/or sinks. The intuition is 
that a method not only returns its ordinary return value but also whether 
it has terminated abnormally and also the type of the occurred exception. 
Applying the intuition expressed in Figure 4.16, RIFL considers exceptions 
as sources for external methods and as sinks for internal methods. This 
enables to express for example that a given parameter may not influence 
whether a given application-internal method terminates abnormally. 


4.5.2 Joana’s Support for RIFL 


In the following, I will explain how Joana’s RIFL front-end works. In 
particular I will carry out how a RIFL specification is interpreted by Joana 
and how the translation of sources and sinks is performed. I will, as in 
most parts of this thesis, consider only sequential programs. 

Joana implements RIFL 1.1 in most parts. RIFL’s declassification is not 
supported since Joana only supports a form of where-declassification [86] 
but no what-declassification. Furthermore, Joana currently does not support 
the specification of an array’s length as source or sinks. However, this has 
only implementation reasons and should be fixable with reasonable effort. 
The major part of Joana’s RIFL front-end consists of translating a RIFL 
specification S = (D,~, Src, Snk, dom) into queries answerable by Joana. 
The objective is to check whether the RIFL specification S is satisfied. 
Intuitively, a source s may influence a sink t only if information classified 
as dom(s) is allowed to influence information classified as t. More formally, 
this can be expressed as 
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Algorithm 7: Routine for checking a RIFL policy 


Input: a program p, a set Src of sources, a set Snk of sinks, a RIFL 
specification with flow relation ~ 
Result: whether one of the given sources may influence one of 
the given sinks although it must not according to ~~ 
1 foreach s € Src do 
2 | foreach t € Snk do 
3 if dom(s) 4 dom(t) ^ s possibly influences t then 
4 | | return false 


5 return true 


Ys € Src. Vt € Snk. s possibly influences t == dom(s) ~> dom(t). 


In RIFL, sources and sinks lie at the boundary between the application and 
the environment. At a source, information enters the application from the 
environment and at a sink it leaves the application to the environment. 
With ordinary sources and sinks, it is not possible in RIFL to specify 
sources or sinks which completely lie within the application. Furthermore, 
once information is outside the application, it cannot be tracked by Joana 
anymore. So if it leaves the application through a sink and immediately 
enters it again unmodified through a source, it is treated like a fresh piece 
of information with no connection to the piece of information that left the 
application just before. 

But if there can be no intermediate steps within the application, it is 
sufficient to consider each pair (s,t) of sources and sinks individually. 
A check routine is shown in Algorithm 7. It receives a program and a 
RIFL specification and returns whether it can be verified that the program 
satisfies the RIFL specification. If the assigned domains of s and t are 
related, no checking is neccessary: Even if there were an information flow 
between s and t, that would be permitted since their security domains 
relate. Hence, an actual check is performed just for those (s, t), where 
spt. 

It remains to implement the check whether a source s possibly influences a 
sink t using Joana. This is done in a two-step process: 
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1. Translate s into a set Ns,. of PDG nodes and t into a set Ng, of PDG 
nodes. 


2. s cannot influence t if 


(4.3) BS(Nonk) N Nsr = 0 


Wasserrab has shown [164, Theorem 6.1] that a check like the one expressed 
by (4.3) is sufficient for guaranteeing non-interference. Note that such a 
check can be replaced by other more sophisticated checks like RLSOD. 
In the special case that the flow relation ~ on D forms a lattice, we can 
also perform a single instance of Hammer’s IFC check [86] instead of 
performing an individual check for each source-sink-pair. 

In the following, I describe how the first step of the process sketched above 
is performed, namely how RIFL sources and sinks are translated to PDG 
nodes. 


4.5.2.1 Mapping of method parameters, return values and 
exceptional return values 


Joana’s interprocedural PDG representation has special-purpose nodes 
for method parameters and the return values, both at the caller’s and the 
callee’s side. Hence, these kinds of RIFL sources and sinks can be mapped 
directly to PDG nodes. The specifics are summarized in Table 4.2. By 
using the term “root parameter”, I acknowledge the fact that Joana not 
only has parameter nodes for the parameters themselves but also for fields 
reachable from parameters which are read or written within the method, 
either directly by the method itself or indirectly by called methods. Every 
parameter node represents a sets of heap locations which may be modified 
or read. Parameter nodes are connected via parameter structure edges: p is 
connected to q via a parameter structure edge if a heap location represented 
by q may be obtained by dereferencing one of p's heap locations using a 
field access operation. More details about this can be found in the PhD 
thesis of Graf [78]. 


4.5.2.2 Mapping of static fields and object fields 


Static and object fields do not have a single counterpart in Joana’s PDG 
representation. Instead they are mapped to all corresponding heap access 
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source sink 
application method | formal-in formal-out 
called from outside | node for node for the 
the (root) return value 
parameter 
call of environment | actual-out actual-in 
method node for the | node for 
return value | the (root) 
parameter 


Table 4.2: Method parameters and return values as sources or sinks on Joana’s 


layer 
source sink 
non-static field all non-static | all non-static 
heap reads heap writes 
static field static heap static heap 
reads writes 


Table 4.3: Static and non-static fields as sources or sinks on Joana’s layer 


operations. The specifics are summarized in Table 4.3. Joana retains 
sufficient information in its PDG for identifying all reading or writing 
accesses of a given field and also whether these accesses are static or not. 
For example, if an object field A. f is specified as a source, then all non-static 
heap read operations on A. f are located. 

How such a field read operation is represented in the PDG can be seen in 
Figure 4.17. One of the nodes in this structure represents the actual access 
to the heap (highlighted in blue). This node is selected as a source. 
Accordingly, if an object field A.f is specified as a sink, then first all 
write operations to this field are located and the actual field node in the 
corresponding PDG structure (see Figure 4.18) is selected. 

Static fields are handled analogously. 


4.5.2.3 Mapping of arrays. 


RIFL allows for the specification of the content and length of arrays as 
sources and sinks. Since Joana’s RIFL front-end does not support lengths 
of arrays as sources or sinks, I only consider the contents of an array. 
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field-get (v1 = v2.f) 


4 1 


dd (v2) dh (f) 


4 


3 2 
Keen Ce rn field Af 


ce VO 
` vl =v2.f 
exit dd (v1) 
cd’ ‘cd | 
> 4 


array field-get (v1 = v2[v3]) 


1 


dd (v2) dd 3) 


Figure 4.17: Joana’s PDG node structures corresponding to the various heap 
read operations (taken and adapted from [78, Figure 2.31]) - the 
node to which a particular kind of source is mapped is highlighted 
in blue. 


Joana models arrays as classes with exactly one field for the contents of the 
array. Individual array cells are not distinguished. Hence, array contents 
can be handled analogously to object fields. The only difference is that one 
has to be coarser when selecting the appropriate instructions: RIFL only 
distinguishes arrays by element type. For example, it can be specified that 
all int arrays are sources. In such a case, all reads on int arrays are located 
and for each of them the actual content access node is selected (see the 
bottom of Figure 4.17 and Figure 4.18, respectively). 
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static field-set (A.f = vl) field-set (v2.f = vl) 


1 1 
l dd (v2) dd (v1) 
dd (v1) 


1 L base v2 | 
er 
ce 
dd : 
ý Treaa] Id A.f 
> e 
field A.f 
Por | 
dh | 


dh (Af) 
array field-set (v2[v3] = v1) 
t | 
dd (v2) dd (v3) 


3 4 y l 
BEN Proves NR dd (v1) 


- N ce 
: dd o 
> ce 4 
& dd — 


ce F : v2[v3] =v1 


i i 2 dd 
y 
exit 
dh (N) 
cd “cd 
> `a 


Figure 4.18: Joana’s PDG node structures corresponding to the various heap 
write operations (taken and adapted from [78, Figure 2.32]) — the 
node to which a particular kind of sink is mapped is highlighted in 
blue. 


4.6 ırspec: An Information-Flow Security 
Benchmark Suite 


In the scope of our work on RIFL, we developed ırspec, a benchmark 

suite for information flow analysis tools. This was joint work with RS? 
researchers from the groups of Mantel at TU Darmstadt and Beckert at KIT, 
with support from many other RS? researchers. In the following, I will 
describe the motivation behind and the structure of ırspec. Furthermore, I 
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will show some of the results we have produced using 1rsrec. The following 
text is based on the resulting publication [85], to which I contributed Joana 
support. 

Benchmark suites exist for various areas of computer science, like compiler 
research, SAT/SMT solving, theorem proving or model checking. They 
allow for the evaluation of a tool or technique with respect to different 
quality metrics like performance, correctness, precision or completeness. 
With such evaluable quality metrics, it is possible to compare different 
tools. Hence, benchmark suites can be regarded as driving forces of 
innovation and technical progress. 

In a benchmark suite that assesses some form of correctness, samples 
should contain some kind of specification of the expected behavior of the 
benchmarked tool. For example, benchmark suites for compilers usually 
consist of sample programs to be compiled together with several test cases 
for the correctness of the compiled programs.If the compiled program fails 
one of these test cases, there is evidence that the compiler does not behave 
correctly. Hence, it is crucial to have such test cases in order for benchmark 
suites that are evaluated with respect to correctness. 

Ideally, the expectation is specified formally, so that it can be read and 
processed automatically. For instance, the SPEC compiler benchmark suites 
contain test drivers, which execute the compiled samples and compare 
their actual outputs with expected values. 

Formal specifications of expectations can also be found in benchmark 
suites for SMT solving. Here the expectation concerns for example the 
satisfiability of a given instance. SMT-Lib requires benchmark instances to 
state their solvability in the metadata [24, §3.9.3]. 

In the area of information-flow security, we found two benchmark suites: 
SecuriBench [148] and DroidBench [21, 61]. SecuriBench consists of several 
web applications found “in the wild” with known vulnerabilities. Later, 
SecuriBench Micro [149] was distilled from SecuriBench. SecuriBench 
Micro consists of 122 very small web applications, each of which focuses 
on a small set of vulnerabilities. 

Although SecuriBench and SecuriBench Micro were developed to bench- 
mark tools for the analysis of vulnerabilities in web applications, they are 
also suitable for information-flow analysis tools since web vulnerabilities 
can also be interpreted from an information-flow security perspective. 
Indeed, SecuriBench Micro has been used to evaluate information-flow 
analyzers targeting Java (e.g. [168]). 
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Arzt et al. [21] presented DroidBench as a benchmark suite for comparing 
their taint-analysis tool FlowDroid with existing tools for Android. The 
original version consists of 35 small Android apps, each of which focuses 
on some feature of Android. Of these 35 apps, 25 are insecure and 10 are 
secure (according to an intuitive specification). Later, DroidBench was 
extended considerably: The current DroidBench 2.0 consists of 119 apps, 
99 of which are insecure and 20 of which are secure. 

For a benchmark suite in information-flow security, such a formal spe- 
cification consists of two parts: A formal specification of the security 
requirements for the given sample and the ground truth, a short inform- 
ation whether the given program satisfies this specification. Then, an 
information-flow can be evaluated automatically as follows: First, it is 
fed with the program and the requirements specification and performs its 
security analysis. Then it outputs whether it deems the given program 
secure or insecure with respect to the given specification. This output is 
then compared with the expected output. 

Neither SecuriBench Micro nor DroidBench provides a machine-readable 
specification of the information-flow requirements. Instead, they provide 
some hints in the comments of their samples. 

With ırspec, we provide a collection of samples together with a machine- 
readable specification so that tools can be evaluated and compared auto- 
matically. We use RIFL to provide formal security requirements and a short 
text file to indicate whether the program satisfies these formally specified 
security requirements or not. 

In detail, each sample consists of the following data: 


Sample Kernel The sample kernel comprises the program itself together a 
RIFL specification and a ground truth. The RIFL specification describes 
formally what it means for this program to be secure. The ground 
truth specifies whether the given program is expected to satisfy the RIFL 
specification. 


Sample Meta-Information The sample meta-information provides further 
descriptions of the sample. For one, it associates the sample with a number 
of tags, which serve as a categorization mechanism for the samples. An- 
other meta-information is the minimal RIFL version that a benchmarked 
tool must support to parse the RIFL specification. Lastly, since RIFL 
has no formal semantics, each sample needs to provide some security 
semantics that have been considered when classifying a sample as secure or 
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insecure. For the classification of the samples in ırsrec, we consider four 
formal security properties: termination-insensitive non-interference for the 
Abstract Datvix Language (TIN-ADL) [121], sequential and probabilistic 
non-interference (SN/PN) [31], and the flow*-predicate [27]. These are 
sufficient for Joana, JopRorp, Cassandra and KeY, the four tools con- 
sidered in this work. The security property TIN-ADL is enforced by 
Cassandra[121], SN/PN is enforced by Joana as well as Jopror for se- 
quential (resp. concurrent) programs, and the flow*-predicate is enforced 
by KeY[27]. 


Sample Interpretation The purpose of the sample interpretation is to 
provide convincing arguments that the sample kernel is meaningful. 
It consists of three parts: 


e a description of the program itself, 


e a description of the intuitive security requirements for this program, 
i.e. what it means intuitively for this program to be secure, and 


o a faithfullness argument that the RIFL specification matches the intuitive 
security requirements. 


The core of ırspec consists of 80 samples. The core samples have been 
provided by RS? researchers over the course of several years. Apart from 
that, ırspec also comprises the 122 original samples of SecuriBench Micro 
and 30 additional samples that were derived from them. 

As an extension, IFSPEC incorporates a machine-processable version of 
DroidBench 2.0. A second extension comprises examples whose RIFL 
specification make use of declassification. 

To demonstrate the usefulness of ırspec, we ran four information-flow 
tools on its samples and reported and discussed our findings. 

In the following, I summarize these discussions, with a focus on JoANa’s 
and Joproıp’s results. 

We use terms that are commonly used to assess properties of classification 
tools. In the following, I introduce these terms. An information-flow 
tool that processes a sample produces two possible analysis results: Either 
it considers the sample secure or it considers it insecure. We refer to 
the former as a positive result (as in the analysis could not find a potential 
information flow) and to the latter as a negative result (as in the analysis found 
a potential information flow). 
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ground truth analysis result combined 


secure negative true negative 
secure positive false positive 
insecure negative false negative 
insecure positive true positive 


Table 4.4: The four possible analysis results when rated with respect to the 
ground truth 


Apart from that and as I already elaborated on, each of ırspec’s samples 
comes with a ground truth which specifies the sample as secure or insecure. 
Now, if we compare the analysis result with the actual ground truth, we 
yield four possible combinations that can be thought of as “rated analysis 
results”, i.e. the analysis result together with the assessment whether the 
analysis result matches the sample’s ground truth. 

The four possible combinations are listed in Table 4.4. 

This can also be expressed in terms of the formalisms introduced in 
section 3.1. Evaluating the analyses on a number of samples can be 
thought of evaluating empirically the four sets 


PIPE GAP kA 
PIPE PAP tad 
PIPE GAP EA 
PIPE OMPLAd 


(true positive 
(false negative 
(false positive 


oo 


{ ) 
{ ) 
{ ) 
{ ) 


(true negative 


for a property ¢ that expresses that the given program is secure w.r.t. to 
the specification”. 

Let #5 be the number of secure samples and #I be the number of insecure 
samples, respectively. For a fixed analysis tool, we use #TP, #FP, #TN, 
#FN to refer to the number of true positive, false positive, true negative 
and false negative analysis results, respectively. Analogously, let #P be 
the number of positive analysis results and #N be the number of negative 
analysis results. Hence, we have 


#5 = #TN + #FP 


22Note that @ has to express security instead of insecurity due to our usage of soundness. 
P y y 8 
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#1 = #TP + #EN 
#P = #TP + #FP 


#N = #TN + #FN 


Based on these numbers, several quantities can be derived that can be 
useful in assessing an analysis tool. In our paper about 1rsPEc, we used 
two of them, recall and precision. These two quantities also have been used 
to assess other information flow analysis tools like FlowDroid [21]. 


e The recall measures how many insecure samples yield a positive 
analysis result. 


#TP #TP 


(pee 
recat pp, ATPSHEN 


The recall always lies between 0 and 1. A recall of 0 means that the 
analysis tool never returns a positive result for any insecure sample, 
whereas a recall of 1 means that the analysis tool yields a positive 
result for all insecure samples. Looking at the formula, we see that 
the recall is low if the number of false negatives is high. In this sense, 
one could say that the recall is a measure of soundness of an analysis 
tool, at least for the given set of samples. 


e The precision measures how many samples with positive analysis 
result are actually insecure. 


#TP #TP 


precision = YP = #TP #FP 


The precision also lies between 0 and 1. A precision of 0 means that 
the analysis never returns a positive result for an insecure sample or, 


3Note that there are other metrics that may be more adequate in assessing an information 
flow tools’ actual precision than the one defined in the following. However, also note that 
the metrics we picked are supposed to be an example for evaluations that can be performed 
with ırspec. Hence, such a discussion lies outside of the scope of this work. 
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conversely, that all its positive results are false positives. Conversely, 
a precision of 1 means that the analysis tool has no false positives. In 
this sense, one could say that this quantity is a measure for actual 
the precision of an analysis tool, at least for the given set of samples. 


tool target language|#samples #soap samples| TP TN| FP FN|recall precision 


Cassandra DBC 232 109 68+79 15 |40+30 0 |100% 67.7% 
JOANA JBC 232 0 139+0 35 | 50+0 8 |94.6% 73.5% 
JopRoip DBC 232 3 136+2 32 |52+1 9 |93.9% 72.3% 

KeY JSC 232 208 7+138 12 |5+70 0 |100% 65.9% 


Legend: JSC=Java source code, JBC=Java bytecode, DBC=Daivix bytecode 
Figure 4.19: Overview of benchmark results — cf. [85, Fig. 5] 


Figure 4.19 shows the results of running the four analysis tools Cassandra, 
KeY, Joana and Joprorp on rrsrec. It lists the respective numbers of true 
positives, true negatives, false positives and false negatives and also the 
recall and precision values derived from these numbers. 

Note that apart from returning a normal result, an analysis tool may also 
crash for a given sample. This may be due to a bug but also due to the 
fact that the sample uses a feature that cannot be treated by the respective 
analysis tool. We interpreted such cases as positive results and call them 
soundly over-approximated, or soap for short. The number of soap samples 
are reported separately for each analysis tool, both the total number and 
how many of false positives and true positives where due to sound over 
approximation (denoted as +n). 

In the following, I want to discuss Joana’s and Joprorp’s results in more 
detail. Discussions of the other tools’ results can be found in our article on 
IFSPEC [85]. 

The results of Joana match the ground truths for 174 of the samples in 
ırspec. The 50 false positives are mainly caused by the fact that Joana 
over-approximates actual program behavior. For instance, Joana does not 
reason about values and does not rule out control flow which is actually 
impossible due to algebraic invariants. Other sources of imprecision 
include array handling (Joana does not distinguish between different cells 
of the same array) and exceptional control flow. 

The eight false negatives are due to two reasons. Seven false negatives 
are caused by the usage of reflection: Joana tries to handle reflective code 
but leaves it unresolved if it fails in doing so. The resulting PDG is then 
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incomplete. The second reason is that Joana models static initializers 
improperly: In one example, the leak is caused by the fact that in Java, 
class initializers are executed lazily. Joana on the other hand assumes that 
all class initializers are executed upfront and hence misses the leak because 
it assumes that the leaking statement is executed at a time when no secret 
information is available yet. 

The benchmarking results for Joproıp show differences in 11 samples. 
These appear to be caused by Joproıp’s Datvix frontend, which not only 
reads in the bytecode but also performs simple intraprocedural analyses on 
it. In three examples, Joana could deliver a result while JopRorp crashed. 
In five examples, Joana did not report a flow and JoDroid did. Possible 
reasons for this may include differences in the handling of static initializers 
and the analysis of exceptional control-flow. Three more differences appear 
to stem from a bug in JopRorp’s modelling of multidimensional arrays. 
We also ran Joprorp on the 119 DroidBench samples that are integrated 
into IFSpec. JoDroid delivered the expected results on 67 of them (54 
true positives, 13 true negatives) and unexpected results on 52 samples 
(seven false positives, 45 false negatives) — this corresponds to a recall of 
54.6% and a precision of 88.5%. The false negatives shed light on Joprorp’s 
limits which I already elaborated on in subsection 4.4.3 (in particular 
subsubsection 4.4.3.3): It currently only has rudimentary support for 
Android features like intents and dynamic broadcast receivers and does 
not detect entry points corresponding to graphical interfaces. Also, the 
results clearly show that the stubs we used for Joprow are insufficient as 
they do not reflect the dependencies of the actual library methods. 


4.7 SHRIFT- System-Wide HybRid Information 
Flow Tracking 


In the following, I report on SHRIFT, a collaboration with the group of 
Pretschner at TU Munich. The general idea of the SHRIFT approach 
is to use static information flow analysis to improve the precision and 
runtime performance of a usage control and enforcement system. We also 
implemented the approach using Joana and demonstrated it on a case 
study. 
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The following summary is largely based on the resulting publication [122]. 
I concentrate on the motivation for this work and a brief description on 
its approach, with a focus on aspects of my contribution that were not 
covered by the paper. For detailed results and their discussion, I refer the 
interested reader to the original article. 


4.7.1 Background and Motivation 


Usage control [132] is an extension of access control. Apart from the 
question “who is allowed to access this data?” it is also concerned with 
usage policies (“how is this data allowed to be used after access has been 
granted?”), data flow tracking mechanisms (“what is allowed to happen to 
this data?” or “what must happen to this data?”) and runtime enforcement 
mechanisms (“what happens if the policy is violated?”). 

A major challenge for effective usage control is the fact that data may exist 
in different representations and/or on different system layers. For example, 
“don’t copy this picture” may mean don’t send an e-mail to which this picture 
is attached in an e-mail client, don’t copy this file on the operating system 
layer or don’t copy&paste this picture in an image editor. 

As a possible solution to this challenge, it has been proposed (a) to model 
usage control polices in a representation-independent language and (b) 
to track and enforce these policies on multiple layers of abstraction using 
a distributed approach [135]. However, multiple monitors running in 
parallel and communicating with each other may incur a significant 
runtime overhead and it may be the case that monitors are not available 
for every layer of abstraction. 

A remedy for the absence of a dedicated monitor is to rely on conservative 
estimation: For example, if a dedicated monitor for a process is not 
available, an OS-level monitor would treat the process as a “black box” 
and assume that every output of the process may result from any sensitive 
input this process has come in touch with. However, this may lead to a 
phenomenon called label creep: Due to over-approximation, the system 
falsely assumes that a piece of data is compromised with high data and 
prevents necessary actions on it because according to the system’s policy, 
they are not allowed. In the worst case, this may lead to an unusable 
system. 
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4.7.2 Approach 


SHRIFT aims to improve on the “black box”-approach described above. Us- 
ing a static information flow analysis, we compute an over-approximation 
of the data flows between the sources and the sinks a given application 
imports data from and exports data to, respectively. Then the application 
is instrumented with a lightweight runtime monitor which, instead of 
performing full data-flow tracking, consults the result of the static analysis 
phase every time a sink is executed to report to the OS-level monitor a 
list of sources which may have contributed to the piece of data which is 
exported by the sink. 

This way, SHRIFT may increase precision in comparison with the “black 
box”-approach and at the same time reduce the runtime overhead of a 
dedicated application runtime monitor communicating with the system’s 
monitor. 

We provided and exemplified an implementation of the SHRIFT approach 
by using Joana as the static information flow analysis. Moreover, we 
evaluated our approach in terms of precision gain with respect to the 
black box approach and performance gain with respect to a fully dynamic 
analysis. Our evaluation showed that by employing a lightweight runtime 
monitor using the result of a static information flow analysis like Joana, it is 
possible to obtain a significant performance gain in comparison with a fully 
dynamic approach and being more precise than the black box approach 
while at the same time retaining a reasonable amount of soundness. 

We applied our approach to the following example”, which is visualized 
in Figure 4.20: 

A company enforces the policy “upon logout, delete every local copy of 
customer data” to prevent clerks from working with outdated material. Upon 
every login, a clerk must download from a central server a fresh version of the 
customer data he is interested in. In this setting, a clerk uses the JZip application 
to compress multiple customer data (E, F) into a single archive file (File 3), 
which he then sends to the company server using JFTP. 

This example illustrates that precision is crucial: If data-flow tracking is 
imprecise, then not only customer data but also additional resources which 
are vital to the system’s functionality, such as the Zipper’s configuration 


*4Here, I show a slightly adapted version of the scenario description in the original paper 
[122, page 372]. 
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Figure 4.20: Example scenario on which we demonstrated our SHRIFT approach 
(taken from [122, p. 372]) 


file, may be deleted. Moreover, it is important that the usage control system 
is able to distinguish the two different channels FTP works with: A data 
channel is used for the data to be sent (in this case the zipped customer 
data), whereas a control channel is used for commands and credentials. 
With the black box approach, once customer data has been read, every 
write operation is assumed to contain customer data. Hence, even the 
credentials written to the control channel by the client and the database 
are subject to deletion. 

In the following, I describe how Joana was used to execute the static 
analysis phase. 

Input for the static analysis is a list of sources and sinks to consider. It 
is important to notice that usually the list of descriptors is provided to 
the analysis by a security expert. In general, this list may depend on the 
application under analysis, since an application can e.g. use JNI to call its 
own native libraries. 

In general, to be independent from the concrete application, we represent 
sources and sinks as pairs (m,p) where m is a method and p is a parameter 
of m. In the following, we call such pairs descriptors. A descriptor (m, p) 
represents parameter p of every invocation of m in the application code. It 
is notated in the format which is also used by Java’s class file format”. For 
example, the descriptor (FileInputStream.read([B), param 1) represents the 
byte array passed as first parameter to any call of the method read(byte[]) 
of class FileInputStream. 

Consider the code snippet shown in Listing 4.14, taken from our running 
example. Here, we want Joana to consider the first parameter of the 


5See e.g. The Java Virtual Machine Specification, Java SE 8 Edition, §4.3.3. 
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call at line 10 as a source and the first parameter of the call at line 
11 as a sink. To a certain extent, the descriptors have to be chosen 
manually, e.g. by reading the API documentation and then deciding which 
methods/parameters are relevant. For example, one may consider all 
variants of FileOutputStream.write() together with appropriate parameters 
as sinks. 


1 FileOutputStream fos = new FileOutputStream(file); 
2 ZipOutputStream zos = new ZipOutputStream(fos) ; 

3 List<String> fileList = this.generateFileList(); 
4 byte[] buffer = new byte[1024]; 

5 for (String file : fileList) { 

6 ZipEntry ze = new ZipEntry(file); 

7  zos.putNextEntry(ze); 

8  FileInputStream in = new FileInputStream(file); 


9 int len; 

10 while ((len = in.read(buffer)) > 0) 
11 zos.write(buffer, @, len); 

12 in.close(); 

13 } 


Listing 4.14: Java code fragment for Zipper application 


However, it may be the case that applications do not invoke source or sink 
methods directly. Consider again Listing 4.14: In line 2, a FileOutputStream 
is wrapped into a ZipOutputStream. When line 11 is executed, ultimately 
FileOutputStream.write() will be called, but not directly from application 
code. To also cover such cases, the descriptors have to be more general. 
One approach is to list every method manually and explicitly. This may be 
error-prone because methods may be missed. We chose another approach: 
We list only methods of the most general I/O classes java.io. InputStream, 
java.io.OutputStream, java.io.Reader and java.io.Writer. After that, they 
are extended automatically using the following rule: If (m,p) is a source 
descriptor and m’ overrides m, then also (m’,p) is a descriptor. This rule can be 
implemented by analyzing the class hierarchy of the given program. 

Still, this may not suffice. For example, JZip also contains a call to the 
method Properties. 1load() which takes an input stream as parameter and 
uses it to fill a properties table. This method is not included by the above 
rule because Properties itself is not an I/O class. For this reason, the 
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descriptors are again extended automatically by the following rule: If 
(m,p) is a descriptor, m’ may call m and p’ is a parameter of m’, then (m’,p’) 
is also a descriptor. This rule can be implemented using a call graph of the 
application, which is also built and used during PDG construction, so it 
can be reused here. 

Once the descriptors have been extended, they can be used to find the 
locations of the sources and sinks in the application and map them to 
appropriate PDG nodes. 

Joana then computes the outcome of this phase: a table that lists, for each 
sink, all the sources that may influence this sink. An example is depicted 
in listing 4.15. 


<source> 
<id>Sourcel</id> 
<location>JZip.zipIt(Ljava/lang/String;Ljava/lang/String; )V:191</location> 
<signature>java.io.FileInputStream.read([B)I</signature> 
<return/> 

</source> 

<source> 
<id>Source2</id> 

</source> 


COPNDUFPWNFH 


11 <sinks> 

12 <sink> 

13 <id>Sink1</id> 

14  </sink> 

15 <location>JZip.zipIt(Ljava/lang/String;Ljava/lang/String; )V:185</location> 
16 <signature>java.util.zip.ZipOutputStream.write([BI1)V</signature> 
17 <param index="1"/> 

18 </sink> 

19 <flows> 

20 <sink id="Sink1"> 

21 <source id="Source1”/> 

22 </sink> 

23 </flows> 


Listing 4.15: Static analysis report listing sinks, sources and their dependencies 


4.7.3 Results 


In the following, I give a summary of the results of our evaluation of the 
SHRIFT approach. I concentrate on the Joana part. 

As Zipper application, we used JZip, a simple command-line application 
written by us that uses the built-in ZIP functionality of the Java stand- 
ard library and Apache Commons CLI [60] (Version 1.2) to implement 
command-line features. Without libraries, it has 293 LoC. 
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The FTP client JavaFTP was downloaded from SourceForge [109]. It does 
not use any libraries apart from Java’s standard library and consists of 
2082 LoC. 

All measurements were conducted on a system with a 2.6 GHz Xeon-E5 
CPU and 3GB of RAM. We ran Joana on JZip and JavaFTP with four 
different points-to analyses. For each points-to analysis, we considered. 
two variants with respect to control dependencies. In variant DI (“direct 
and indirect flows”), Joana built the normal PDG, including control- 
dependencies. In variant D (“only direct flows”) it built a PDG without 
control dependencies. This was realized by first building the normal graph, 
removing control-dependencies and summary edges from this graph and 
finally re-computing the summary edges. 

Each run consists of four steps: First, Joana built the call graph of the 
given program and extended the given sources and sinks as described in 
subsection 4.7.2. Then, Joana built the program dependence graph and 
identified sources and sinks in it according to the extended lists. Finally, 
Joana used context-sensitive slicing to count the number of source-sink- 
pairs that were connected in the PDG. 


4.7.3.1 Performance 


Table 4.5 shows the overall time that Joana took for each configuration, 
along with rough estimates of the sizes of the respective PDGs. The times 
for the D and DI variants are aggregated by reporting the time for the 
slower variant. Note that although the D variant takes more time for the 
PDG construction, it may take less time in the slicing phase since there are 
less edges - the overall time for the D variant may therefore be roughly 
the same or even smaller. The graph sizes are reported for the DI variant. 
We can see that the points-to analysis has a massive impact on the graph 
size and also on the overall time needed to perform the analysis. For 
object-sensitive points-to, the number of edges can be 6.4-6.6 times as high 
as for 0-1-CFA, resulting in an overall time that is 6.7-6.9 times as high. 


4.7.3.2 Precision 


Table 4.6 shows the number of source-sink-connections for both examples 
for all considered configurations and variants, which we call flows for 
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points-to graph size (DI) time (sec.) 
#nodes #edges 


E 0-1-CFA 6.82x10* 8.65 x 10° 32 
> 1-CFA 1.77x10° 1.95 x 100 64 
= 2-CFA 3.98x10° 4.54 x 10° 153 
object-sensitive 3.06x10° 5.73 x 10° 220 

a 0-1-CFA 1.10x10° 1.44x 10° 53 
N 1-CFA 2.04x10° 2.13 x 10° 82 
2-CFA 3.47x10° 3.61x10° 185 
object-sensitive 4.50x10° 9.15 x 10° 353 


Table 4.5: Overall time of static analysis phase and PDG sizes for JavaFTP and JZip 


short. Moreover, Table 4.6 gives a simple and coarse estimation of the 
precision gain obtained. This value is computed as 


# flows 


ze #sources - #sinks 

and compares the respective static analysis result to a conservative black 
box approach where every source is assumed to possibly flow to every sink. 
Such an approach would correspond to a static analysis with a precision 
of 0. Hence, the higher the precision value, the larger the precision gain of 
using the respective static analysis is?®. 

According to this measure, we see that the choice of points-to analysis 
is crucial for JoaNna’s precision and has to be adapted to the application 
under analysis. For JavaFTP in the DI variant, object-sensitive points-to 
analysis makes the analysis 6.6 times as expensive as 0-1-CFA, without 


26Note however, that the term “precision” is not entirely appropriate, since we deliberately 
give up soundness in the D configurations. In [122], we argue why it may be appropriate to 
ignore control dependencies for our application. 

?7The actual sources and sinks may vary with different points-to analyses because 
Joana uses points-to analysis for call graph construction and particularly for the identifica- 
tion of reachable code. Also, [122] reports 84% for JZip/object-sensitive/D, possibly due to 
a typo in the paper. 
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points-to #sources #sinks #flows (precision %) 


DI D 

a 
= 0-1-CFA 9 46 274(38%) 214 (51%) 
g 1-CFA 9 46 187(58%) 119 (73%) 
= 2-CFA 9 46 187(58%) 118 (73%) 
object-sensitive 9 46 272(38%) 114 (74%) 
© 0-1-CFA 10 56 428(24%) 321 (43%) 
N 1-CFA 10 55 414 (25%) 257 (53%) 
2-CFA 10 55 246 (55%) 123 (78%) 
object-sensitive 10 55 239 (57%) 91 (83%) 


Table 4.6: precision values for JavaFTP and Zip? 


any precision gain. Also 2-CFA does not have any advantage over 1-CFA 
although its runtime is 2.4 times as high. For JZip in the DI variant, on 
the other hand, the higher costs seem to pay off. For the D variants, the 
precision gain of a more precise points-to analysis is more visible. Joana 
uses points-to analysis not only to construct its call graph but also heavily 
for the computation of the heap dependencies. Hence it is plausible that 
a more precise points-to results in more precise heap dependency and 
therefore data dependency graph. 


4.8 Modular Verification of Information Flow 
Security in Component-Based Systems 


In a collaboration with the group of Beckert at KIT [83], we also applied 
Joana in the area of information flow security verification of component- 
based systems. 

In an instantiation of the approach proposed in the article, we used Joana 
to verify user-provided service-level security properties. From these 
properties, first-order formulas are generated that express that component- 
level security follows from service-level security and that system-level 
security follows from component-level security. These formulas can be 
discharged using a first-order theorem prover like KeY. 
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The approach is both modular with respect to services and components 
and with respect to service-level security properties. This not only means 
that the security of the whole can be derived from the security of its parts 
but also that service-level properties verified by Joana can be re-used to 
show different overall security properties. 

We applied the approach to a case study, in which we verified the security 
of a system implemented in Java. 


4.9 Summary and Conclusion 


In this chapter, I gave an overview of some of the activities within the 
RS? priority program, with a focus on the achievements of the program 
paradigms group and the sub-project Information Flow for mobile components. 
In section 4.2, I described the advances in our work on probabilistic non- 
interference, particularly how we developed relaxed low-security observational 
determinism (RLSOD), a criterion that (a) can be verified using PDGs and 
control-flow checks, (b) improves the precision (under certain scheduling 
assumptions) on earlier criteria based on observational determinism and 
(c) enforces probabilistic non-interference. 

After that, I reported on seven collaborations within RS? in which JOANA 
was involved. 

In section 4.3, I elaborated on how Joana and the KeY theorem prover can 
be combined to verify cryptographic properties of a prototypical E-Voting 
system. 

In section 4.4, I presented JoproID, an extension of Joana for Android apps 
and showed how it was integrated into the RS? certifying app store, the 
artifact of the RS? reference scenario Software Security for mobile devices. 
Subsequently, in section 4.5, I reported on the joint work on the RS? 
Information Flow Language (RIFL), a language to specify information-flow 
properties in a language- and tool-neutral way. Then, I described Joana’s 
RIFL support in subsection 4.5.2. An application of RIFL was shown 
in section 4.6: RIFL was used to provide an information-flow security 
benchmark suite that is also fully supported by Joana. 

Last but not least, I elaborated on two other collaborations that showed 
how a static information flow control tool like Joana can be applied (a) 
to improve the precision and performance of usage control (section 4.7) 
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and (b) to aid a theorem prover in the verification of information-flow 
properties for component-based systems (section 4.8). 

All in all, this chapter demonstrated that our progress and our collabora- 
tions within the RS? project contributed to the establishment of PDG-based 
static analysis techniques in the realm of security analyses. Joana is a 
matured tool whose theoretical foundation has been firmly stabilized. It 
can be applied to a wide variety of scenarios, ranging from advanced 
security checks of mobile apps over the verification of cryptographic 
security properties to the improvement of usage control systems and 
the simplification of theorem proving approaches to the verification of 
component-based systems. With Joana’s support for RIFL and ırspec, 
a well-founded baseline can be drawn that should drive and foster the 
state-of-the art of static security analysis tools in the future. 
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And in the end, the love you take 
is equal to the love you make. 
THE BEATLES 


A Common Generalization Of 
Program Dependence Graphs 
and Control-Flow Graphs 


In chapter 3, I considered the interprocedural versions of slicing on program 
dependence graphs (PDGs) and data-flow analysis on control-flow graphs. 
In subsection 3.3.4, I identified similarities and argued that slicing on PDGs 
can be considered as a very simple data-flow analysis instance. 

In this chapter, I am going to further develop these ideas. I will introduce 
interprocedural graphs (IGs), a general graph model that is less restricted than 
interprocedural control-flow graphs (ICFGs), yet still enables data-flow 
analysis. Both interprocedural control-flow graphs and interprocedural 
program dependence graphs can be considered as IGs. This makes 
available a whole range of data-flow analyses for PDGs. 

IGs generalize ICFGs as defined in subsubsection 3.2.1.2 in several aspects. 
For one, the procedures of ICFGs each have only one entry and one exit. 
IGs lift this restriction and allow for multiple entries and exits. Secondly, 
in an ICFG, each call has exactly one corresponding return. In contrast, 
IGs allow for arbitrary corresponding relations between calls and returns. 
A third aspect in which IGs generalize ICFGs is that ICFGs - at least in the 
context of classical data-flow analysis — usually make some reachability 
assumptions. For data-flow analysis on IGs, these assumptions are not 
neccessary. 

The data-flow analysis variant I introduce in this chapter is also a gener- 
alization of its counterpart on interprocedural control-flow graphs that 
I already considered in subsubsection 3.2.2.2. These generalizations are 
neccessary to properly consider slicing as a data-flow analysis. 
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As I have carved out in subsection 3.3.4, two generalizations are necessary 
to make this idea work. In the following, I am going to briefly describe 
them. 

The first generalization is concerned with the notion of interprocedurally 
valid paths. Remember that subsubsection 3.2.2.2 introduced this notion 
to characterize the properties of interprocedural paths considered by a 
data-flow analysis (cf. page 56). 

Intuitively, an interprocedurally valid path 7 respects call semantics. This 
amounts to two properties. Firstly, if a procedure is called on 7 and it 
returns later, then the call site to which it returns must match the call site 
from which the call started in the first place. Secondly, if a procedure 
returns on 7, then n must also contain a matching call. The notions 
developed in this chapter only require that the first property is satisfied. 
This matches the notion of interprocedural validness that one usually 
makes on PDGs to define slicing. 

The second generalization is concerned with the fact that a slice is defined 
usually not with respect to a fixed entry point but rather with respect to an 
arbitrary node. In subsection 5.4.2, this leads to a version of the objective 
function MOVP that has - unlike the version in subsubsection 3.2.2.2 (cf. 
equation (3.8)) — not one argument, but two. 

This chapter is organized in four parts. In section 5.1, I develop the notion 
of valid sequences and important variants. I base these notions on classic 
results from the theory of balanced parenthesis. My approach is to first 
introduce intuitive definitions and then derive inductive definitions from 
them. After that, in section 5.2, I present interprocedural graphs and 
my notion of valid paths, which is based on the theory developed so far. 
Next, section 5.3 presents data-flow analysis on interprocedural graphs. 
Finally, I conclude this chapter in section 5.4 by showing a variety of use 
cases for data-flow analysis on IGs, including already existing PDG-based 
approaches and several graph-theoretic notions. 


5.1 Nesting Properties of Symbol Sequences 
In this section, I develop the notion of validness for symbol sequences. Valid 


sequences form the basis of valid paths, which I will define in section 5.2 
along with interprocedural graphs. 
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Validness is concerned with symbol sequences that essentially consist 
of opening and closing parentheses and connects two different ways 
of assigning closing parentheses to opening parentheses. One of them 
counts parentheses to assign every opening parenthesis at most one closing 
parenthesis such that the part between the two is balanced. The other way 
is expressed as a correspondence relation that is used to relate opening 
parentheses and closing parentheses that are compatible. Validness then 
demands that if two parentheses match, then they must be compatible 
with respect to the correspondence relation. 

This section is organized as follows: In subsection 5.1.1, I introduce 
the matching relation that assigns each opening parenthesis in a given 
sequence at most one closing parenthesis and vice versa. This relation 
makes use of balanced sequences, which in turn can be characterized using 
a formalization of the process of counting parentheses. It turns out 
that relation-theoretic properties of the matching relation can be used to 
characterize two different kinds of partially balanced sequences that become 
important in defining the building blocks of valid sequences and paths. 
Partially-balanced sequences are introduced in subsection 5.1.2. After 
that, subsection 5.1.3 is concerned with the second kind of assigning 
opening and closing parentheses to each other: It introduces a relation that 
specifies which parentheses are compatible. Using this relation, I define 
valid sequences. Additionally, I introduce valid counterparts for (partially- 
)balanced sequences. Finally, after I have introduced valid sequences in 
subsection 5.1.3, I derive inductive definitions for valid sequences and 
their partially-balanced variants in subsection 5.1.4. 


5.1.1 Balanced Sequences 


In this section, I introduce balanced sequences. I do this according to Knuth 
[107] with the help of two functions which formalize the process of counting 
parentheses. 

In the following I consider symbol sequences over E = Ejntrg U Egat U Eret 
where Ejntra, Eggi] and Eye are pairwise disjoint. Elements of E.,; are called 
opening parentheses, call symbols or just calls. Elements of Eye are called closing 
parentheses, return symbols, or just returns. Elements of Ejytyq are called inner 
symbols. Later, the opening parentheses will model calls of procedures and 
the closing parentheses will model returns from procedures. The inner 
symbols will later model intraprocedural edges. With Callpos(r) := {i € 
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range(r) | Ti € E..ı} and Retpos(m) := {i € range(n) | T; € Eyer} I denote 
the set of call and return positions in n, respectively. 


Definition 5.1. Let n € E* be a symbol sequence. 
1. The content c(7) of 7 is defined as follows: 
c(e) =0 


e(r) Fi ife € Ecall 
c(n:e)=4c(n)—-1 ifeeEse 
e(r) ife E Eintra 


2. The deficiency d(7) of n is defined as follows: 
d(e) =0 


E3 max{d (7), —c(7)} ife € Ecall U Eintra 
au En -c(n)+1} ifee Eye 


Given a symbol sequence 7, the function c computes the difference between 
the number of call symbols and the number of return symbols of a given 
symbol sequence, wheres d computes the maximal shortage of call symbols 
among the prefixes of 7. I give some examples to illustrate how c and d 
work. 


Example 5.2. Let Eintra = {*}, Ecay = {(} and Eyer = {)}. 


1. For mı = ()(x), we have 


iļ0]|1]2|3]ļ4 
Zara 
Fra ER 
d(x“) |0|0|0|0 |o 
2. For m2 = ())), we have 
iļo|1]2 |3 
ZUR RA 
era) | 1 | 0 | -1 | -2 
d(ns') | 0| 0/1 | 2 
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3. For nz = (()()), we have 


2 1.0.02. 1221°8° 2] 
NE 
(Cone a care ae 
d(ns') | 0] 0]0[0/0] 0 
4. For na =)()((*, we have 
ilo |1]2 lee Se 
AMEME 
c(z¥) | -1| 0] -1|0|1/1 
CES |1|1 |1|1]|1 
5. For nz; = ()(x(x, we have 
iļo0]1]2|3ļ]4ļ|5 
me I (CI) ICJ] (| * 
ea) tr] 
das) |0|0}|0]0|0/0 


Remark 5.3 and Lemma 5.4 formalize important properties of c and d. 


Remark 5.3. c is additive: c(m1 nn) = c(nı) + c(n2). 
Proof. This follows by induction on 71. m 


Lemma 5.4. For every n € E*, we have 


1. e(r) = |Callpos(r)| — |Retpos(r)| 


2. d(n) = max{-c(0) | 0 € Prefixes(r)} 

3. d(n) = 

4. d(n)=0 = c(n)>0 

Proof. e The first two claims can be proven by a straightforward 


induction on the length of r. 


e For the third claim, we observe that (1) e is always a prefix of 7, (2) 
c(e) = 0 (by definition of c) and conclude from the second claim that 


(3) d(x) > ~c(e) = 0. 
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e Since x is a prefix of itself, we may apply the second claim and 
obtain d(m) > -c(n) or, equivalently, -d (r) < c(7). For d(z) = 0, 
this implies c(7) > 0. 

oO 


Now I define what it means for a symbol sequence to be balanced. Intuitively, 
in a balanced sequence we can match the call positions with the return 
positions in a well-nested fashion. 

However, initially I define balancedness as a mere property about the counts 
of opening and closed parentheses in a symbol sequence. Balancedness 
has two requirements: Firstly, there must be as many call symbols as return 
symbols in rt. Secondly, for every prefix of 7 there cannot be more return 
symbols than call symbols. The first property guarantees that a bijective 
function between the call positions and the return positions is possible, 
while the second ensures that it is always possible to map each call position 
to a later return position. 

Going back to Example 5.2, we see that 71 and 73 are intuitively balanced, 
whereas 712, n4 and 75 are not: 72 has more return symbols than call 
symbols, while 75 has more call symbols than return symbols. Moreover, 
as 74 Starts with a return symbol, it cannot be extended to a balanced 
sequence. 

The examples show that the balancedness of sequences can indeed by 
characterized using c and d. 


Definition 5.5. A sequence n € E* is called balanced if c(m) = d(n) = 0. 
The set of balanced symbol sequences is written as Bal(E). 


The following lemma gives an easy characterization of balancedness which 
we will make use of later. 


Lemma 5.6. A sequence n € E* is balanced iff c(n) = 0 and c(@) > 0 for all 
prefixes 0 of Tt. 


Proof. This follows easily from Definition 5.5 and Lemma 5.4. m 


5.1.1.1 The Matching Relation 


Now I introduce a relation vz which relates opening and closing positions 
in a symbol sequence x to each other. The relation was also introduced by 
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012 345 6 7 8 9 10 11 
((aa)(sas)e ) 


| — J 


Figure 5.1: An example sequence with its matching relation. The e; are inner 
symbols, there is one call symbol “(” and one return symbol “)”. 
Connected symbols are related by the matching relation. 


Knuth [107], albeit not formally. An example for the intuition behind vz 
can be seen in Figure 5.1. 


Definition 5.7. For a sequence n € E* we define the matching relation 
Vy < Callpos(rı) x Retpos(rt) by: 


(Lj) © Vn = i< GAG E Ecg A Tj € Evet A mil is balanced 


In the following, I am going to state three important properties of vz 
that reflect the intuitive expectations toward a properly defined matching 
relation. 

Firstly, Theorem 5.8 states that vz never relates a call position to multiple 
return positions or, conversely, a return position to multiple call positions 
(compare Knuth[107, p. 271]). 


Theorem 5.8. For any symbol sequence n € E*, vz is left- and right-unique. 
Proof. We show left- and right-uniqueness separately. 


right-uniqueness: Let (i, j) € vn and (i, j’) € vz. Assume, for the purpose 
of contradiction, that j # j’. Without loss of generality, we may assume 
that j < j’. Since m/l is balanced, we know that d(r/‘/’l) = 0. Because 
rt] is a prefix of ni|, we get c(nl/]) > 0 by Lemma 5.4. However, since 
Tj € Ere and mil is balanced (which means that c(rdii l) = 0), we also 
have: 
en) = c(i!) -1 = 0-1 = -1 

This is a contradiction, so the assumption must be false and it must be 
j=. 
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Figure 5.2: Illustration of the different cases of well-nestedness of vz 


left-uniqueness: Let (i,j) € vn, (i’,j) € vz. Assume, for the purpose of 
contradiction, i + i’. Without loss of generality, assume i < i’. Since nll 
is balanced, we have e( nll l) = 0. Since both nli” | and ml’! are prefixes 
of mltil, we have c(n!"|) > 0 and c(nli”]) > 0 by Lemma 5.4. In fact, 
since ny € Eo, we even have (#1) = c(nli” |) +1 > 0. But then, using 
Remark 5.3, we can conclude 


(nl) == (nl) — cn“) < Cc il) = 0, 
so that e(r” -i l) < 0, which contradicts the balancedness of nl” Jl. 
o 


Secondly, the one-sided totality properties of vz can be used to assess 
whether 7 is balanced or not. This is the statement of Theorem 5.9. 


Theorem 5.9. For any symbol sequence n € E*, the following conditions are 
equivalent: 


(a) nis balanced. 
(b) vr is left- and right-total, i.e. a bijective function Callpos(r) — Retpos(r). 


The third property, which is given in Theorem 5.10, states that vz relates 
call and return positions in a well-nested fashion. 

More specifically, the respective sections between two matching position 
pairs never overlap. 

For an illustration, see Figure 5.2. Given two pairs (i, j), (i’, j’) € vn of call 
and return positions that are related by vr, the corresponding index ranges 
li, j] and |i’, j’] are either disjoint or one of them is contained in the other. 


Theorem 5.10. Given n € E*, assume that (i, j), (i’, j’) € Vn. Then one of the 
following statements is true: 
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2. 1S fell 
3. Winl,r]=0 

Proofs for Theorem 5.9 and Theorem 5.10 can be found in section A.1 and 
Theorem 5.9, respectively. 


5.1.2 Partially-Balanced Sequences 


Theorem 5.9 suggests that the totality properties of v„ can be used to 
classify sequences with respect to their balancedness properties. This 
motivates the following definition. 


Definition 5.11. We denote by Left(E) < E* the set of symbol sequences m such 
that vn is left-total and by Right(E) < E* the set of symbol sequences ™ such that 
Vry is right-total. If n € Left(E) U Right(E), we also call n partially balanced. 


Remark 5.12. 
Le ft(E) A Right(E) = Bal(E) 


Proof. This follows from Theorem 5.9. oO 


5.1.3 Valid Sequences 


The property of balancedness only considers call and return symbols in 
terms of their numbers. In particular, in a balanced path it is only ensured 
that every call symbol is matched by a return symbol and vice versa. 
However, it is not ensured that return symbols also correspond to their 
matching call symbols. 


Figure 5.3: A balanced but invalid symbol sequence — positions related by vz are 
connected. 
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As a simple example, consider the symbol sequence depicted in Figure 5.3. 
Here there are two distinct call symbols ( and [ and two distinct return 
symbols ) and ]. We find that vn = {(0,3), (1,2)}, hence 7 is balanced. 
But the symbols at the positions related by vz do not belong together. To 
exclude such sequences, I introduce a correspondence relation ® C E sqq) X Eret 
that specifies which call symbols belong to which return symbols. In the 
example, the obvious choice for ® is {((,)), (L I)}- 


Definition 5.13. Let n € E* be a symbol sequence. 
r is called valid if 

V(i, j) € Callpos(r) x Retpos(r).(i,j) € vn — (ni, ni) € ® 
I will denote the set of valid symbol sequences as Val (E). 


Basically, this property says that if a call has a matching return (in terms of 
position in the path), this return actually corresponds to the call according 
to the relation. The sequence from our example is invalid, since (0,3) € vz 
but (9, n?) ¢ ®. 

In the following, I fix a correspondence relation ® C Eea X Eret- 


Definition 5.14. Let n € E* be a symbol sequence. 

1. nis called ascending if n is valid and vr is left-total. 

2. is called descending if n is valid and vz is right-total. 

3. T is called same-level if r is both ascending and descending. 


4. With AscSeq(E), DescSeq(E), SLSeq(E), I denote the sets of ascending, 
descending and same-level sequences, respectively. 


Example 5.15. Let Eintra = {x}, Eca = {<a, <p} and Eret = {>a, >p}, Further- 
more, assume that ® = {(<q, >a), (<p, >»)} and consider 


de 
def 


def 
13 = <a<p>p>a>b 
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def 
T4 = <a<a>a<p>b 
def 
T5 = >p>p Laa 
1. Then my is invalid: We have (0,1) € vr,, but (<a, >p) ¢ È. 


2. We have Callpos(m2) = {0,1}, Retpos(m2) = {2,3} and vr, = {(0,3), (1,2)}. 
Now it is easy to see that Tc is valid and both left- and right-total. Hence, T is a 
same-level sequence. 


3. We have Callpos(m3) = {0,1} and Retpos(nz) = {2,3,4}. Moreover, we have 
Vna = {(0,3), (1,2)}. This means that 73 is valid and vr, is left-total, but not 
right-total, since there is no i € Callpos(m3) with (i,4) € Vra. Hence, nz is 
ascending, but not same-level. 


4, Analogously, we see that m4 is valid and that vn, © {0,1,3} x {2,4} is 


right-total, but not left-total. Hence, T4 is descending, but not same-level. 


5. Finally, va, = 0 C {0,1} x {2,3}, so m5 is trivially valid but neither left- nor 
right-total. Hence, nz is neither ascending nor descending. 


Since the left- and right-totality of vz is equivalent to the balanced-ness of 
mt, the same-level property can also be expressed using balanced-ness. 


Theorem 5.16. 7 € E* is same-level if and only if it is balanced and valid. 


Proof. By definition, 7 is same-level if and only if it is valid and vr is 
bijective. By Theorem 5.9, this is the case if and only if 7 is valid and 
balanced. m 


In the following, I show that valid, ascending and descending sequences 
are closed under taking contiguous sub-sequences. This becomes clear 
relatively quickly, if we think about cases in which the respective totality 
properties are maintained: Taking an arbitrary sub-sequence of rn can 
only remove or shift the positions appearing in vz. Hence, validness 
is maintained by this operation. Left-totality may be destroyed, if we 
take a suffix and potentially remove a return position by this. However, 
taking prefixes maintains right-totality. Hence, we can conclude that 
descending sequences are closed under taking prefixes. Analogously, 
right-totality is maintained by taking suffixes since taking a suffix only 
removes return positions and does not hurt the matching for the remaining 
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return positions. Hence, ascending sequences are closed under taking 
suffixes. 

For the proof of Theorem 5.18, I need a technical lemma, which I state and 
prove before I proceed with Theorem 5.18. 


Lemma 5.17. If n = 71-72-73 € E*, then 
1. ranger (nz) = {i+ Inı| | i € range(m2)} 
2. Vi, j € range(nz). (i,j) Evm > (i+Iml,j+lmıl) € vr 


Proof. We observe that 


T = pelitablreal+iegl-1] 


which is equivalent to 


Vi € range(nn). rd, = n™lH, 


From this, both claims can be proven easily. o 
Theorem 5.18. The following statements are true. 


1. Valid sequences are closed under taking sub-sequences, in particular under 
taking suffixes and prefixes. 


2. Ascending sequences are closed under taking suffixes. 
3. Descending sequences are closed under taking prefixes. 


4. Taking a prefix of an ascending sequence or a suffix of a descending sequence 
yields a valid sequence. 


Proof. 1. If mis valid and n’ = nl’ isa sub-sequence of n, then 7’ still 
has the validity property, as can easily be seen. 


2. Let m be ascending and nr) be a suffix of n. Write n = |n|. Let 
k € range(n@/) be a call position in nr). Then (x2/)* = n**j. Because vz 
is left-total, there is a return position / € range(7) such that (k + j,I) € vz. 
From this, it follows that l > k + j. Hence, we can write I = (l- j) +j, 
so that l — j € range(n”}). Then, (k+ j,1) € vn implies (k,I- j) € v „<j by 
Lemma 5.17. Thus, we have shown that V_>j ÍS left-total. 
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3. Let r be descending and 7! be a prefix of n. Let 


l € Retpos(n“]) C Retpos(r) 
be a return position in rn“). Due to right-totality of vz, we find a k € 
Callpos(1) such that (k,l) € vn. This means in particular that k < I. With 
I < j we get k < j so that we can conclude (k,1) € v <j- This proves that 
v „sj is left-total. 


4. Both ascending and descending paths are valid and according to the 
first statement, valid paths are closed under taking suffixes and prefixes. 
(m 


5.1.4 Inductive Definitions 


In this subsection, I derive inductive definitions for the various classes of 
sequences that I have introduced so far. Istart with characterizing balanced, 
left-total and right-total and finally all sequences inductively. Afterwards, 
I consider their valid counterparts and give inductive definitions for 
same-level, ascending, descending and valid sequences. 

Proofs for the following three theorems can be found in section A.3. 


Theorem 5.19. Bal(E) is the least subset X of E* with the following properties: 


TEX eeE; 
(Ball) (Bar) = — 


eeX neeX 


TEX EX Ccall € Ecall eret € Eret 


(Bal3) - 
Tl: Eoall TU" Eret € x 


Theorem 5.20. Left(E) is the least subset X of E* which has the following 
properties: 


TEX e €E; UE 
(Left1) —— (Left2) ee ee 
€ 


EX TM-e EX 


TEX n E Bal (E) ecall € Bein eret € Eret 


(Left3) 


TC * ecall © n’ -eret E X 
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Theorem 5.21. Right(E) is the least subset X of E* which has the following 
properties: 


TEX e € Eintra U Ecal 


(Right1) (Right2) 


EE Te EX 


neX mn’ €Bal(E en €E RN: 
gy N ner R 
TU ecall TU * eret E X 


Next, Theorem 5.22 that every sequence can be split up into a left- and 
right-total sequence in a specific way. This is a specific version of a theorem 
already considered by Knuth (cf. [107, Lemma 1]). I am going to apply this 
property in chapter 7. 


Theorem 5.22. For every symbol sequence, there is i € range(rt) such that every 
symbol sequence n € E* can be split up into n = n“ - n% such that 


(5.1) n“ e Left(E) 
(5.2) n=! € Right(E) 
(5.3) n&Left(E) — ie Callpos(r). 


Proof. Define the set of unfinished call positions in 7 as 


U call def {i € Callpos(r) | Yj € range(n). (i, j) € va}. 


Now we make a case distinction on whether Ucan is empty or not. If 
Ua = 9, then n € Left(E). Then we can choose i = |r. 

Now consider the case that Usa + 0. Let i € U..ı be the least element of 
Uea. Now we show 


(1) T1 H asie Left(E) 
(2) no] nèi € Right(E). 


(1) Let i’ € Callpos(nı) < Callpos(m). Then i’ < i and, due to the choice 
of i, there must be j € range(m) such that (i’, j) € vz. This implies nl 
is balanced and hence that j < i, since otherwise mil would contain 
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the unmatched call 7;, in contradiction to the balancedness of mil. In 
addition to j < i we also observe j + i, since m’ € Esq and nI € E, and 
Eca N Eret = Ø. Thus, we have j € range(71) and therefore (i’, j) € vr. 


(2) We show mz € Right(E) by induction on nn € E*. This is clear for 
rn = €. So let m2 = T, -e. Our induction hypothesis says that 7, € Right(E) 
and we have to show that 72 € Right(E) as well. We proceed with a 
case distinction on e. If e € Ejntrqg U Ecaj, then we have nn € Right(E) by 
Theorem 5.21. So we assume e € Eye. Let j € Retpos(m2). We have to find 
ig € Callpos(rtz) such that (ig, j) € Vz. This follows from the induction 
hypothesis if j € Retpos(n,), so we may assume j = |72|—1. In this 
case, we choose ig as the greatest unmatched call position in 72. Such a 
position must exist since i is an unmatched call position in 7 and therefore 
in nt. Furthermore, we have ig < j. This is because Eca N Eret = Ø 
and it, = e € Ere. Finally, we have to show that nlio | 
lio, il 


is balanced. By 


Theorem 5.9, it suffices to show that 7 contains neither unmatched 

call positions nor unmatched returns positions. We show the two claims 

separately: 

e Assume, for the purpose of contradiction, that mol contains an 
unmatched call position i4. This position would have the property 
i, > ig, which is a contradiction to the maximality of ig. Hence, such 
a position cannot exist. 

e Assume, for the purpose of contradiction, that nl | contains an 
unmatched return position and let jg be the least such position. 


Then ml would be balanced. Firstly, it cannot contain unmatched 
call positions, due to the maximality of ig. Secondly, it also cannot 
contain unmatched return positions, due to the minimality of jo. 


Moreover, we have ig < jo, nA € Ecaj and rn € Ever, so that we obtain 
(io, jo) € Vn, a contradiction to the choice of jg as unmatched return 
position. 


oO 


Corollary 5.23 (cf. [107], Lemma 1). Every symbol sequence m € E* can be 
split up into n = nı - T2 such that vy is left-total and vn, is right-total. 


Proof. This is a direct consequence of Theorem 5.22. m 
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5.1.4.1 Inductive Definitions for valid sequences 


Before I actually derive and prove correct inductive definitions for the valid 
variants of partially-balanced sequences, I compile a couple of observations 
about the closure properties of same-level, ascending, descending and 
valid sequences. Proofs can be found in section A.3. 

Firstly, I observe that appending inner symbols does not do any harm. 


Lemma 5.24. 1. Ifr € AscSeq(E) ande € Ejntra U Eret, then T -e € AscSeq(E). 
2. If n € DescSeq(E) and e € Eintra U Ecay, then t- e € DescSeq(E). 
3. If n € SLSeq(E) and e € Ejntyg, then T- e € SLSeq(E). 


Secondly, appending a same-level sequence destroys neither validness nor 
the respective totality property of the matching relation. 


Lemma 5.25. Let x € Val(E) andr’ € SLSeq(E). Then the following statements 
hold: 


1. nn’ is valid. 

2. If r € Bal(E), then m- n’ is same-level. 

3. fneLeft(E), then m- n’ is ascending. 
4. If nm € Right(E), then m- n’ is descending. 


Lastly, same-level sequences are closed under surrounding with a corres- 
ponding call-return pair. 


Lemma 5.26. If n € SLSeq(E), eca € Ecall» eret € Eret and (eca, eret) € ®, 
then ecaj ` Te: eret € SLSeq(E). 


With these three observations in mind, it is now relatively clear how the 
inductive definitions for the partially-balanced sequences have to be mod- 
ified in order to obtain inductive definitions for their valid counterparts. 
All we have to do is adapt the respective clause that is concerned with 
appending balanced sequence to make sure that it maintains validity. 
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Theorem 5.27. The same-level sequences are the least subset X of E* with the 
following closure properties: 


TEX e € Ejntra 


(SL-SEQempty) ——  (SL-SEQintra) 


EEX neeX 


TEX nT EX ecall € Ecall eret € Eret (ecall, Eret) eo 


(SL-SEQjnter) 
TC: Ecall z m * eret E X 


Proof. By Theorem 2.19, we have to show that 
1. SLSeq(E) satisfies SL-5EQempty,SL-SEQintra ANd SL-SEQinter- 


2. SLSeq(E) is contained in the least subset Xọ < E*that satisfies 
SL-SEQempty/SL-SEQintra and SL-SEQinter- 


We prove the two claims separately. 


1. SLSeq(E) satisfies sL-sEQempty, because € is balanced by Ball and trivially 
valid. Moreover, with Lemma 5.24 we see that SLSeq(E) also satisfies 
SL-SEQintrq. Finally, Lemma 5.25 and Lemma 5.26 imply SL-SEQ;nter- 


2. By structural induction on 7 € Bal(E) we show 
Yr € Bal(E). n € Val(E) — TE Xo. 


This implies SLSeq(E) = Bal(E) N Val(E) € Xo. 
Ball If x = e, then n € Xo by SL-SEQempty- 


Bal2 Letn = n’-ewithn’ € Bal(E) ande € Eiņntra: Assume that n € Val(E). 
Then n’ € Val(E) by Theorem 5.18. This implies n’ € Xo by induction 
hypothesis. With sL-sEQintrg, We get nT = n’ -e € Xo. 


Bal3 Let nm = nl’: Coan: T” -eret With 1’, T” € Bal(E), ecall € Ecall, eret € Eret 
and assume that n € Val(E). Choose i,j such that n“ = n’, n! = 
Coalls niil = n” and ni = ey. Then we observe that (i,j) € vn by 
definition. Since rn € Val(E), it follows that (esq, eret) € ®. Furthermore, 
by Theorem 5.18, both z’ and n” are valid. Application of the induction 
hypothesis to n’ and n” yields n’, T” € Xo. Now we can apply SL-SEQjyter 
obtain that n = n’ eu © T > eret € Xo. 
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oO 


Theorem 5.28. The set of ascending sequences is the least subset X of E* with 
the following properties: 


TEX e € Eintrag U Eret 


ASC-SE an ASC-SE 
( Qempty) BER ( Qasc) FEN 


TEX T € SLSeg(E) ecall € Ecall Cret € Eret (Ecall, eret) c 


ASC-SEQ,]) 
( . Tl ecall TU + eret € X 


Proof. By Theorem 2.19, we have to show that 
1. AscSeq(E) satisfies ASC-SEQemptyrASC-SEQgsc ANd ASC-SEQ,), and 


2. AscSeq(E) is contained in the least subset Xọ < E* that satisfies 
ASC-SEQempty,ASC-SEQasc and ASC-SEQg]. 


We prove the two claims separately. 


1. AscSeq(E) satisfies asc-sEQempty, because € € Left(E) by Leftl and e 
is trivially valid. Moreover, with Lemma 5.24 we see that AscSeq(E) 
also satisfies ASC-SEQgsc. Finally, Lemma 5.26 and Lemma 5.25 imply that 
AscSeq(E) satisfies AsC-SEQ,. 


2. Let Xo be the least subset of E* that has the closure properties 
ASC-SEQempty,ASC-SEQgsc aNd Asc-sEQ,. By structural induction on 7 € 
Left(E) we show 


Yr € Left(E). n € Val(E) = > TE Xp. 
This implies AscSeq(E) = Left(E) N Val(E) < Xo. 


Leftl If n = e, then 7 € Xo by Asc-sEQempty- 


Left2 Let n = n’ -e with n’ € Left(E) and e € Ejytra U Eyer. Assume that 
n € Val(E). Then n’ € Val(E) by Theorem 5.18. With n’ € Left(E), we can 
apply the induction hypothesis and get n’ € Xp. With Asc-sEQusc, we get 
m=’ -e€ Xo. 
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Le ft3 Leta = nr. ecall ` Tt’. eret with rn’ € Left(E), m” E Bal (E), Ecall E Eji 
eret € Eyep and assume that n € Val(E). Define i, j such that n“ = n’, 


T = Call, nliil = n” and nÍ = e,t. Then we observe that (i,j) € vn by 
definition. Since rn € Val(E), it follows that (ecaj, eret) € ®. Furthermore, 
by Theorem 5.18, both z’ and n” are valid. Application of the induction 
hypothesis to n’ yields n’ € Xo. Furthermore, n” is both balanced and 
valid, which means that n” € SLSeq(E). Now we can apply asc-sEQ,; and 
yield that n = n’ - egy T” -eret € Xo. 


oO 


Theorem 5.29. The set of descending sequences is the least subset X of E* with 
the following properties: 


TEX e € Eintra U Ecall 


(DESC-SEQempty ) oe (DESC-SEQgesc) Tee x 


meXne SLSeq(E) Ccall E Ecall 
eret € Eret (€calt, eret) e® 


DESC-SEQ 
sl) Tl * Ecall‘ m eret € X 


Proof. The proof is very similar to the proof of Theorem 5.28. m 


Theorem 5.30. The valid sequences are exactly the concatenations of the ascend- 
ing and the descending sequences. In particular: 


1. If m1 is ascending and Tq is descending, then Tq - T3 is valid. 


2. Every valid symbol sequence n € E* can be split up into n = 711-72 such 
that Tq is ascending and Ty is descending. 


Proof. I show both statements separately. 


1. Let n = 71-7 and (i,j) € vn. First we observe that it must be 
either i,j € rangen(m1) or i,j € range;(m2): Assume, for the purpose 
of contradiction, that this is not the case. Then, since i < j, it must 
be i € ranger(nı) and j € range; (m2). But note that 7 is ascending. 
Hence, there is j’ € range; (7) with (i, j’) € vz, E vn. But then we have 
(i,j) € vn and (i, j’) € v„ with j’ < j, in contradiction to Theorem 5.8. 
Thus, the assumption must be false and we have either i, j € rangen (71) or 
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i, j € rangen (n2). In either case, it follows that (nf, ni) € ®, since both 7 
and 7 are valid. 


2. Let 7 be a valid symbol sequence. By Corollary 5.23, we can split up 
r into T = 7 - 72 such that vy is left-total and vy, is right-total. Since 7 
is valid, by Theorem 5.18 both 7, and 7 are valid. It follows that 77 is 
ascending and 77, is descending. 


5.2 Interprocedural Graphs 


In this section, I introduce the graph model over which I will later define 
data-flow analyses. This graph model is intended to be general enough 
to cover both the classical interprocedural control-flow graphs (cf. Defini- 
tion 3.2) and also other graphs like program dependence graphs. 


Definition 5.31. Given a finite set P of procedure labels, an interprocedural 
graph 


G = (N, Einiges Ecallı Eret, P, Ẹ, Nentry, Nexit) 
consists of 


e a set of nodes N = pep Np such that 
Vp,p' eP.p#zp => NyNNy =0 
e a set of intraprocedural edges Ejytra = Upep Ep such that 
Vp € P. Ep © Np X Np and Yp, p' € P. Ep O Ep =0 


e sets Ecaj, Eret < Up p'ep Np X N, of call edges and return edges with 
the property 


Eintra N Ecall = Eintra N Ere = Ecalı N Ere = 0, 


e a correspondence relation ® S Evy X Ever, and 
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e sets Nentry, Nexit < N of entry and exit nodes, respectively, such that 


— every node with an incoming call edge is an entry node, 
Yn EN. (an! € N. Je € Eu. n >n => nE Nentry), 
— every node with an outgoing return edge is an exit node, and 
Vn EN. (an € N. Je € Ern n! => nE Neit), 


- no node is an entry node and an exit node at the same time. 


Nentry N Nexit = 0. 


I define Ejnter = E cat U Eret and call its elements interprocedural edges. I 
refer to each (Np, Ep) as procedure graph. According to the definition of 
interprocedural graphs, for each n € N there is exactly one p € P such that 
n € Np. I call p the procedure of n and write it as proc(n). Occasionally, I 
will consider an interprocedural graph as a directed graph (N, E). Then I 
ignore the additional structure and use 


def 
E = Eintra U call U Ever. 


In the rest of this thesis, I will assume that Nentry and Neyit are given but will 
not mention them explicitly when specifying an interprocedural graph. 


Definition 5.32. Let G = (N, Eintra, Ecall, Eret, P, ®) be an interprocedural 
graph. Then I define the following special nodes: 


1. A call node is a node that has outgoing call edges. I write N sqq for the set of 
call nodes. 


2. A return node is a node that has incoming return edges. I write Nye for the 
set of return nodes. 


The following example shows that both interprocedural control-flow 
graphs and interprocedural program dependence graphs are subsumed 
by Definition 5.31. 
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Example 5.33. 1. Interprocedural control-flow graphs according to Defini- 
tion 3.2 can be considered as interprocedural graphs with the following additional 
properties: 


e Every procedure graph has exactly one entry node sp and exactly one exit 
node ey. 
P 


e Ọ is a bijective function, i.e. it is left-total, left-unique, right-total and 
right-unique. 


2. Interprocedural program dependence graphs as described in subsubsec- 
tion 3.3.2.2 on page 65 can be considered as interprocedural graphs. We consider 
parameter-in edges as elements of Eca and parameter-out edges as elements of 
Eyet. Then the entry nodes are either ordinary procedure entries or formal-in 
nodes. Exit nodes are either ordinary procedure exits or formal-out nodes. Call 
nodes are either ordinary call nodes or actual-in nodes. Return nodes are either 
ordinary return nodes or actual-out nodes. 


Definition 5.34. Let G = (N, Eintra, Eca, Eret, P, ®) be an interprocedural 
graph and let s,t € N. 
1. A path n € Paths(G) is called 
e same-level path if n € SLSeq(E), 
e ascending path if n € AscSeq(E), 
e descending path if n € DescSeq(E), and 
e valid path if n € Val(E), 
where SLSeq(E), AscSeq(E), DescSeq(E) are defined with respect to the corres- 


pondence relation ®. 


2. I define 


SL, ASC, DESC, VP : Nx N — 2Paths(G) 


by 


SL(s, t) Wf SI Seq(E) N Pathsc(s, t) 


def 


ASC(s,t) = AscSeg(E)N Pathsc(s,t) 
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d 
DESC(s, t) 2f DescSeq(E) N Pathsc (s,t) 


VP(s,t) SF ValSeq(E) N Pathsg(s, t) 


In the following, I will use these functions also as path sets. Particularly, I will 
write SL for the set of paths n such that there is s,t € N with n € SL(s,t) — 
analogously for ASC, DESC and VP. 


By combining the inductive definitions of the valid sequences and their 
partially-balanced variants with the inductive definition of Paths(G), I can 
derive inductive definitions for SL, ASC, DESC and VP, respectively. 


Theorem 5.35. SL is the least subset of N x N x 2E* with the following closure 
properties: 


neX(s,t) t St ee Eina 


SL-EMPTY 
( ) m-e € X(s,t) 


zen) (SL-INTRA) 


TE ecall ` TU -eret € X(s,t) 


Proof. According to Theorem 2.19, we need to show 

1. SL has the closure properties sL-EMPTY, SL-INTRA and sL-sL, and 

2. SL C Xo where Xg is the least subset of N x N x 2E* with the closure 
properties SL-EMPTY, SL-INTRA and SL-SL. 

We show both claims separately. 


1. We show that SL has the properties sL-EMPTY, SL-INTRA and SL-SL. 


SL-EMPTY Lets € N. Then e € Pathsg(s,s) by patH-EmMpty. Moreover, 
e € SLSeq(E) by SL-SEQempty. Together, it follows that e € Pathsg(s,s) N 
SLSeq(E) = SL(s,s). 

SL-INTRA Let s,t’,t € N, n € SL(s,t’) and t £ t with e € Ejntra. From 
m € SL(s,t’) we have n € Pathsc(s,t’) and n € SLSeq(s,t’). From n € 


Pathsc(s,t’) and t’ + twe get n-e € Pathsc(s,t) and from n € SLSeq(E) 
and e € Ejytra we have m-e € SLSeq(E) by SL-SEQjytra. Together we have 
m:e € Pathsc(s,t) NSLSeg(E) = SL(s,t). 
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st-s Let s,n, no, nı,t € N, eca € Ecallı eret € Eret, T € SL(s,n) and n’ € 
e 

SL(no, n1) with n cnl no, nı “3 tand (ecall, eret) € ®. Then we have T- ea - 

Tt’ -eret E SLSeq(E) by SL-SEQjnter- Moreover, T- Eoajj TV + eret € Pathsg(s, t) 

follows from SL(s,n) < Pathsg(s,n) and SL(ng,n1) < Pathsg(no, n1) by 

PATH-EXTEND and Lemma 2.23. 


2. Let Xo be the least subset of N x N x 2E* with the closure properties 
SL-EMPTY, SL-INTRA and sL-sL. Using the induction principle induced by 
Theorem 5.27, we show 


Yr € SLSeq. Ys,t € N. n € Pathsg(s,t) => neXo(s,t) 

Let ne SLSeq and s,t € N with 7 € Pathsc(s,t). Then we need to show 
neXo(s,t). 

SL-SEQempty : If n = e, then from n € Pathss(s,t) we get s = t, hence 
T € Xo(s,t) by sL-EMPTY. 

SL-SEQjntra : Assume n = n’ -e with n’ € SLSeq and e € Ejnty. By 
Lemma 2.24, from n € Pathsc(s,t) we yield t € N with n’ € Pathsc(s,t’) 
and t’ 5 t. By induction hypothesis, we get n’ € Xo(s,t’). This implies 
nt € Xo(s,t) by SL-INTRA. 

SL-SEQjnter : Assume n = T + cay + T” ere With m,” € SLSeq and 
(eca re) € ®. By splitting up n and applying Lemma 2.24 to 


e 
n € Pathsc(s,t), we obtain n,ng,nı with n’ € Pathsc(s,n), n es 


n” € Pathsg(no,nı) and nı ey By induction hypothesis, applied to 77’ 
and n”, we get n’ € Xo(s,n) and n” € Xo(no,nı). This implies n € Xo(s,t) 
by SL-sL. 


oO 


Theorem 5.36. ASC is the least element X € Nx N > 2E* with the following 
closure properties 


meX(s,t’) t >t ee EintrqUEret 
m-e € X(s,f) 


(ASC-EMPTY) (Asc-asc) 


e € X(s,s) 


call 


neX(s,n) n > no n’eSL(ng,nı) n 3 t (calls eret) EP 


ASC-SL 
( ) TE: ecall TÜ eret EX(S, t) 
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Proof. This can be shown analogously to Theorem 5.35. m 


Theorem 5.37. DESC is the least element X € N x N — 2E* with the following 
closure properties 
DESC-EMPTY ) ————— 
( ) e € X(s,s) 
nEX(s, t) t St e€ Eintr U Ecl 
m:e € X(s,t) 


(DESC-DESC) 


call 


n€ X(s,n) n ® no n € SL({ng,m) ny 3 t (eca eret) € ® 


DESC-SL 
( ) Tl Coq TU + eret € X(s,t) 


Proof. This can be shown analogously to Theorem 5.35. m 
Theorem 5.38. For all s,t € N, VP(s,t) can be characterized as follows: 


(VALID-ASC-DESC) 
VP(s,t) = {nı na | dn € N.my € ASC(s,n) A T2 € DESC(n, t)} 


Proof. This follows from Theorem 5.30, Lemma 2.23 and Lemma 2.24. O 
Theorem 5.39. The following statemens are true. 


1. Valid paths are closed under taking sub-paths, in particular under taking 
suffixes and prefixes. 


2. Ascending paths are closed under taking suffixes. 
3. Descending paths are closed under taking prefixes. 


4. Taking a prefix of an ascending path or a suffix of a descending path yields a 
valid path. 


Proof. This can be derived by combining Remark 2.25 and Theorem 5.18. 
Oo 


Theorem 5.40. For all s,t,t’ € N, we have 


(5.4) Yn € ASC(s,t). Yn’ € ASC(t,t’). mn’ € ASC(s, t’) 
(5.5) Vm € DESC(s,t). Yn’ € DESC(t,t’). n- n’ € DESC(s,t’) 
(5.6) Yr € VP(s,t). Yn’ € SL(t,t’). n:n € SL(s, t’) 
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Proof. The first two statements can be shown using Lemma 2.23, The- 
orem 5.20, Theorem 5.21 and the definitions of ascending and descending 
paths. 


For the third statements, by Theorem 5.38 it suffices to show the respective 
property for descending paths. But this follows from Theorem 5.37. 
oO 


With an additional regularity restriction of ®, I can show that same-level 
paths end in the same procedure that they started in. 


Remark 5.41. Assume that the correspondence relation ® has the following 
property 


(5.7) (€cail, eret) € = proc(src(ecqy)) = proc(tgt(eret)) 


Then the following statement holds: If r is a same-level path from s to t, then 
proc(s) = proc(t). 
Proof. By induction on nr € SL(s,t). Oo 


Table 5.1 shows an overview of some notions of validness in the literature. 
The publications there can roughly be split into two groups: Those that 
characterize valid paths as suffixes of descending paths and those that 
characterize them as concatenations of ascending and descending paths. 
While the former notion is sensible for contexts in which valid paths are 
supposed to correspond to actual program executions’, the latter notion 
is more general. According to Theorem 5.39, suffixes of descending paths 
are always valid. Conversely, however, interprocedural graphs in general 
may contain valid paths that are not suffixes of any descending path. 
The two notions coincide if additional assumptions are made, as The- 
orem 5.42 states. Note that such assumptions are not made for the rest of 
this thesis. 


Theorem 5.42. Let G = (N, Ejntra, Ecatt, Eret, P, ®) be an interprocedural graph. 
Assume that every procedure graph Gp has a distinguished entry s, and that the 
following conditions hold: 


8They are also called realizable paths for this reason. 
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definition in literature notion of validness 


[86, Definition 2.13] suffixes of descending paths 
[137, p. 4] suffixes of descending paths 
[164, p. 110ff] suffixes of descending paths 
[136, Definition 2.3] suffixes of descending paths 
[65, Definition 2.3] valid paths 
[138, Definition 2.1] valid paths 


Table 5.1: Notions of validness in the literature 


There is a procedure main € P such that the entry Smain Of Gmain reaches every Sp 
using a descending path. 


(main-reach) main € P. Yp’ € Proc. SL(Smains Sp) + 0 
In every procedure graph Gy, every node n € N, is same-level reachable from sp. 
(sl-reach) Yp € . Yn € Np. SL(sp, n) #0 


For every return edge e, there is a corresponding call edge that enters the procedure 
that e starts in: 


(ret-call) Ve € Evep. de’ € Eggy.(e’,e) € ® A tgt(e’) = Sproc(src(e)) 
Then every valid path is the suffix of a descending path starting in Smain: 


(5.8) Vio € VP.Vm,neN. 
T2 € Pathsg(m,n) 
=> Am, € Pathsg (Singin, M). T1 To € DESC (Smain, n). 


Proof. It suffices to show that (5.8) holds for the ascending paths: 


(5.9) Yr € ASC.Vm,neN. 
T2 € Pathsg(m,n) 
=> Am, € Pathsg (Singin, M). T1 Ta € DESC (Smain, n). 


Suppose that (5.9) is true and let n € VP(m,n) be a valid path. Then by 
Theorem 5.38, we obtain mp € N, 71, € ASC(m, mo), 12 € DESC(mo,n) such 
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that rn = T4 : 712. Now we apply (5.9) to 71 and obtain o € Pathsg (Smain, M) 
such that onı € DESC(smain mo). With na € DESC(mg,n), we have 
0 + Tq © T2 € DESC (Smain, n), as desired. 

It remains to show (5.9). We proceed by induction on the number k of 
unmatched return positions in ra € ASC. 


base case (k = 0): If 72 has no unmatched return positions, then 72 € SL, 
because rn» € ASC, which means that rn has also no unmatched call 
positions. Now let m,n € N such that mz € SL(m,n) and let p = proc(m). 
We apply (main-reach) to sp and obtain ni € DESC (Smain, Sp). Moreover, 
we apply (sl-reach) to m € Np and obtain n?’ € SL(sp,m). Now consider 


d 
T1 2 ri: ny. With the help of Theorem 5.40, from 7, € DESC(s main, Sp), 
tT’ € SL(s,,m) and 1» € SL(m,n), we conclude n’ - n? + mt = nı:m € 
1 P 1 1 


DESC (Singin, 1), as desired. 


induction step (k > k +1): Let 72 be an ascending path with k + 1 un- 
matched return positions. The induction hypothesis states that the claim 
is true for all ascending paths with k unmatched return positions. Let 
m,n € N such that rn € ASC(m,n) and let jo be the least unmatched return 
position in 77. Then we write 72 as 


T2 = Thy * ret * TY 
where 
def <j 
reg 0 
Ty = n, € Pathsg(m,no), 


de : eret 
eret = nd with no © nı, and 


def >] 
te = nm, € Pathsc(nı,n). 


for some nọ, nı E N, eret € Eyet- 


Due to the maximality property of jo, 7, contains no unmatched return 
positions. Moreover, it cannot contain any unmatched call position. 
Assume, for the purpose of contradiction, that 7, contains an unmatched 
call position. Then the greatest such position is also a call position in 72, 
which would be matched by the return position jg, in contradiction to 
the choice of jo as unmatched return position. Hence, the assumption is 
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false, which means that all call positions in 7, must be matched. Hence, 
T € SL(m,ng). Moreover, Ty is a suffix of the ascending path nz and 
therefore ascending because of Theorem 5.39. 


Ecall 


Now let p = proc(m). We apply (ret-call) to ere and obtain mg > sp 
such that (e..11, €ret) € ®. Moreover, we apply (sl-reach) to m and obtain 
Tto € SL(sp, m). Now consider the path 


def 
O = eccal: To * Cret * T2 = call * TO * Cret * Tl -eret Ty 


from mọ to no: It is the concatenation of the same-level path e.an - T10 ` Eret 
and the ascending path 72 and therefore ascending itself. Moreover, it 
contains k unmatched return positions because by choice of eca, we have 
(0,1 + jo) € vo. Hence, we can apply the induction hypothesis to 0 and 
obtain o € Pathsg (Singin, no) such that 


0-0 € DESC (Smain, 1). 
With 
def 
T1 = O° cgi] * TO, 


we have 711-72 = 0-0 € DESC (Smain, 1), as desired. 


5.3 Data-Flow Analysis on Interprocedural 
Graphs 
Next, I define data-flow analysis instances for interprocedural graphs. This 


is a general and formal version?’ of the notions I have already described 
in subsubsection 3.2.2.1 on page 48. 


Definition 5.43. A data-flow analysis instance F = (G,L,F, p) consists of 


e an interprocedural graph G = (N, Eintras Ecallı Evet, P, ®), 


2Note that Definition 5.43 omits the initial information init. I will discuss this slight 
modification in subsection 9.2.2. 
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e a complete lattice (L, <), 


e aset F CL yoy L that contains id, is closed under function composition 
and forms a complete lattice with point-wise ordering, and 


e a function p : E —> (L mon L) which assigns a monotone transfer 
function to each edge of G. 


Instead of p(e) I will write fe. I extend this notation to arbitrary paths by 
defining 


(5.10) fe 
(5.11) fre Zz feo fr: 


Next, I want to introduce my generalized variant of the merge-over-all- 
valid-paths solution MOVP. This version of MOVP is more general in two 
aspects: 


1. it not only considers paths that start in a fixed entry node, but takes the 
starting node as additional argument, 


2. it not only considers descending paths but also paths with an ascending 
prefix. 


Moreover, I explicitly do not make any assumptions about reachability. 
Hence, the value MOVP(s,t) not only reflects the resulting value if we 
merge the path functions for all valid paths from s to t, but it also commu- 
nicates whether VP(s, t) is empty or not. In traditional data-flow analyses, 
this is never the case because they only consider s, t where VP(s,t) is not 
empty. However, Lr can still be a valid analysis result value, even if 
VP(s,t) # 0. 

Hence, in order to be able to distinguish between analysis results for 
non-empty and empty path sets, I adjoin F with an additional element 
x that represents undefinedness. Before I discuss the properties of m, I 
give the definition of MOVP in Definition 5.44. Since I will also consider 
Merge-Over-P-solutions for other sets of paths than VP, Definition 5.44 is 
more general than needed right now. 
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© ŒO 


Figure 5.4: Example in which it is important that m kills everything — e is an 
intraprocedural edge 


Definition 5.44. Let P C Paths(G) be a set of paths. The Merge-Over-P- 
solution 
MOP : N xN > Fa 
is defined by 
MOP (s, t) = || fe 
nePNPathsc (s,t) 


Now I discuss the assumptions about and properties of & more closely. 
Firstly, I assume that & is smaller than any element of F. 


(5.12) Vf eFa. n < f 
(5.13) yvfeF.m +f 


This means that it never coincides with any fr: 


(5.14) Ve € E. fe + R 
(5.15) YVf,gEF.fog+m 


These properties ensure that 
MOVP(s,t) = ® if and only if VP(s,t) = 0. 


Moreover, I extend the function composition on F to Fg in a way such that 
® kills every value already computed: 


(5.16) Yf e Fg. f oR =o f =M. 


I make this assumption because I want to compose different values of 
MOVP consistently without explicitly thinking about & or whether the 
corresponding VP sets are empty or not. For illustration, consider the 
graph in Figure 5.4. Since VP(s,t’) = 0, we have MOVP(s, t’) = m. (5.16) 
ensures that I get the same result by computing fe o MOP(s,t). 

Instead of adjoining F with m, I could have made two alternative choices 
that one could make to achieve the same goals. For one, I also could 
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use partial functions N x N — F for my solution space. Then I could say 
that (s,t) does not belong to the domain of MOVP if VP is empty. In my 
approach, I communicate this by letting MOVP(s,t) be & in such cases. 
The other approach would be to restrict F to only allow strict functions. A 
function f : L > Lis called strict, if f(x) = Ly is equivalent to x = Ly. If 
all f € F are strict, then I can use Ax... as bottom element of F to represent 
the merge over the empty path set. 

I decided to use & explicitly because I did not want to restrict the transfer 
functions but also did not want to introduce additional notational overhead 
for dealing with partial functions. I will make use of one additional 
convention: At several places, I will use elements y : Nx N > Fg as 
functions. Whenever I do this and do not explicitly discuss whether y = ® 
or not, I will silently assume y + ®. For instance, if I state equations such 
as W(x) = y, then I will silently assume that y is indeed a function. 

I conclude this section by considering distributivity, an important property 
of transfer functions and frameworks. Distributivity ensures that the 
constraint systems that I show in chapter 6 coincide with their respective 
MOP solutions. 


Definition 5.45. e Let L be a complete lattice and FC L —>mon L be 
a complete lattice of monotone functions that is closed under function 
composition. Then 


1. f €F is called strict, if 


(5.17) fol=1 


2. f € F is called distributive, if 


(5.18) Veg heF.fo(guh)=fogufoh 
3. f € F is called positive-distributive, if 
(5.19) VACFA#0 = fo| |A=| |ifoglgeA} 


4. f € Fis called universally distributive, if it is strict and positive- 
distributive, i.e. if 


(5.20) VACE.fo| |A=| |ifoglgeA} 
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5. F is called strict, distributive, positive-distributive, universally dis- 
tributive if all f € F have the respective property. 


o A data-flow framework instance F = (G,L,F,p) is called strict, distribu- 
tive, positive-distributive, universally distributive if F has the respective 
property. 

In the following, I will use “u.d.” to abbreviate the term “universally distributive”. 
The data-flow framework instances that I consider in this thesis are 
automatically strict because of (5.13), (5.12) and (5.16). Under these 
assumptions, a data-flow analysis framework instance is universally 
distributive if Fa is positive-distributive. However, it is worth mentioning 
that this applies to Fa and not to F: In order for Fg to be positive- 
distributive, F needs to be universally distributive. In this sense, adjoining 
x does not magically make F strict, but at least makes it possible to 
distinguish reachable nodes from unreachable parts of the given graph. 
In chapter 7, I will only consider data-flow analysis framework instances 
F = (G,L,Fa,p) in which Fa additionally satisfies (ACC). For such 
instances, distributivity is equivalent to universal distributivity. 


5.4 Example Instances 


In this section, I want to discuss various data-flow analyses that can be 
expressed and solved using the abstract data-flow framework presented 
earlier. 


5.4.1 Traditional Data-Flow Analyses on Interprocedural 
Control-Flow Graphs 


According to Example 5.33, interprocedural control-flow graphs can be 
regarded as interprocedural graphs. Hence, all traditional data-flow 
analyses in the sense of subsubsection 3.2.2.2 can be expressed as data-flow 
analysis instances in the sense of Definition 5.43. The solution MOVP 
defined in Definition 5.44 is more general, since it does not use the entry 
Smain Of the main procedure as starting point but rather considers all paths 
between arbitrary nodes s and t. Moreover, MOVP merges over all valid 
paths and not over all descending paths and also takes reachability into 
account. I already discussed this in subsection 5.4.2 and section 5.3. 
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5.4.2 Slicing 


As I already pointed out in subsection 3.3.4, slicing on program dependence 
graphs can be expressed as reachability, a very simple data-flow analysis 
instance. We can generalize this further by considering slicing on inter- 
procedural graphs, which are a generalization of interprocedural program 
dependence graphs according to Example 5.33. 

Let G = (N, Entra, Ecall» Eret, P, ®) be an interprocedural graph. 

As for IPDGs, the backwards slice of a node n € N can be characterized 
as the set of nodes which may reach n by a valid path. Analogously, the 
forward slice can be characterized as the set of nodes which may be reached 
by a valid path. 


(5.21) BS(n) = {me N | VP(m,n) #0} 
(5.22) FS(n) = {me N | VP(n,m) #0} 


As in subsection 3.3.4, the reachability data-flow analysis instance 
(G,L,F, p) is defined as follows: 


er 


F% tax, id, Ax} 


d 
p a Ae.id 


{L, T} 


(5.23) 


Now, observe that 
Yr € VP(s,t). fr = id 


Hence, we have 
id if VP(s,t 
movPF(s,t)= || f= | u 
otherwise 
neVP(s,t) 


This allows us to rewrite BS and FS as 


BS(n) = {me N|MOVP(m,n) + a} 
FS(n) = {me N | MOVP(n,m) + m} 


So, by computing MOVP, we can extract BS and FS. 
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5.4.3 Chopping 


Chopping [48, 138] was proposed as a means to make slicing on PDGs 
more focussed. Roughly, the idea is not to go back or forward from a single 
node, but to consider all nodes that may lie on paths between two nodes. 
Like slicing, chopping can also be considered on a general interprocedural 
graph G = (N, Ejntra, Ecait, Eret, P, ®). Given s,t € N, the chop between s 
and t is defined as 


d 
CH(s,t) = {n € N | An € VP(s,t). n enodes(r)}, 


where for a sequence of edges n € E*, nodes(rt) is the set of nodes that 
occur in the symbol sequence: 


d . ; 

(5.24) nodes(r) = {n € N | Hi € range(n). n = sre(n') Vn=tgt(n)}. 
Note that chops and slices actually have a strong connection. For s # t, 
we have s € BS(t) if and only if CH(s,t) # 0. Hence, applications such 
as slicing-based information flow control can also be expressed using 
chopping. 
Chopping can be expressed as a data-flow analysis instance as follows. 

d 

ve ee) 

d 
(5.25) F 2f (AX.(XNA)UB |A,Be2N} 

d 

fe(X) = xu (sre(e), tgt(e)} 


It can easily be seen that (G,L,F,p) is indeed a data-flow framework 
instance with respect to Definition 5.43. 
Moreover, using induction on the length of paths, we can show that 


(5.26) Yr € Pathsc(s,t).fn (X) = X Unodes(n). 


Hence, we have 
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CH(s,t) = u nodes (rt) { definition } 
neVP(s,t) 
= |) Aa { by (5.26) } 
neVP(s,t) 
= | a { rewriting } 
neVP(s,t) 
= MOVP(s,t) (0). { definition } 


Analogously, we can consider the edge chop 


(5.27) ECH(s,t) = = {n € N | an € VP(s,t). n eedges(n)}, 
where 

def e ; 
(5.28) edges(n) = {e € E | Hi € range(n).e = n'.} 


Edge chops can be computed using the following data-flow analysis 
instance. 


1 (2c) 


(5.29) FÍ (Aax.(XNA)UB|A,Be 25} 
fX) ZT Xue 


Like for node chops, it can be easily verified that this indeed satisfies 
Definition 5.43. 


5.4.4 Strong Bridges and Strong Articulation Points 


Strong bridges [95] are a graph theoretical concept that describes the 
connectivity properties of a given directed graph. Intuitively, a strong 
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bridge is an edge that disconnects a graph if it is removed. Strong bridges 
are interesting for applications such as slicing-based information flow 
control. Consider a PDG G = (N, E) and two nodes s,t € N. Remember 
that slicing-based IFC works by computing the backwards slice BS(t) of 
t and checking whether s € BS(t) or not. If s € BS(t), then it is definitely 
not the case that s influences t in any way and if s € BS(t), this may be the 
case. Equivalently, we can also compute the chop CH(s, t) of s and t and 
consider the chop graph Cs + = (CH(s,t), ECH(s,t)). Now, suppose that Cs ¢ 
contains a bridge and we can show that this bridge is actually not justified, 
i.e. G would not contain it if it was obtained using a more precise analysis. 
Then this means that s actually does not influence t. Hence, strong bridges 
can be a tool for eliminating false alarms. This kind of reasoning has been 
applied to PDGs by Beckert, Bischof et al. [26]. 

Strong bridges as considered by, e.g., Italiano et al. [95], can be generalized 
to interprocedural graphs. 

Given an interprocedural graph G = (N, Eintra Ecatt, Eret, P, ®) and s,t € N, 
a strong bridge with respect to s and t is an edge e € E such that e € edges(1) 
for all n € VP(s,t). 

The set of strong bridges is then defined as 


(5.30) SB(s,t) = {e € E | Yn € VP(s,t). e € edges(m)}. 


Note that this is dual to the edge chops defined in (5.27). Hence, a data- 
flow analysis instance for expressing strong bridges can be obtained by 
reversing the partial order used for the data-flow analysis defined by (5.29): 


L = (2,2) 
(5.31) F= ee BEE) 
fe(A) = 
It is easy to see that F is indeed closed under composition and contains 


the identity function. We also note that if f = AX.(X N A1) U By and 
g = AX.(X NA») U Bg, then 


Ute} 


(fUg)(X) = f(X) n g(X) = (X N43) U B3 
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with A3 = (Ay NA) U (Ay N B2) U (A2 N By) and B3 = By N B2. 

Due to the finiteness of E, this makes F a yeas lattice with respect to 
the functional join induced by the join N of (2#, 2). 

The node analogon to strong bridges are A articulation point. A strong 
articulation point is a node that disconnects a given graph if removed. A 
data-flow analysis instance that is able to compute the strong articulation 
points of a given graph can be specified as follows: 


L = (2,2) 
(5.32) F= (AX. (XM A)UB|A,BCN} 


f(A) = AU {sre(e), tgt(e)}. 


5.4.5 Restricting to Paths With Regular Properties 


The reachability analysis shown in subsection 5.4.2 can be generalized 
to language-restricted reachability. In this subsection, I am going to 
demonstrate this for forward reachability and regular languages. I also 
will show two special cases of this. 

Remember that a finite automaton is a quintuple 


(5.33) A = (Q, A, qo, Ao, QF). 
The components of are 
e a set Q of states, 
e an alphabet A, 
e a distinguished state gg € Q which is called the initial state of A, 
e a set Ag E Q xA x Q of transition rules, 
e a set QF < Q of final states. 
Now, I recall the definition of the language recognized by a finite automaton 


= (Q,A, go, Ao, Qf). For this, I define 
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A: E* 322 22 


by 
(5.34) A(e,S) =S 
(5.35) A(m-e,S) = {g € Q| Aq E€ A(n, S). q’ € Aolg,e)} 


Then the language recognized by A can be defined as 


(5.36) L(A) = In € E* | A(7;, {go}) N QF #0) 


It is well-known that the regular languages are exactly the languages that 
are recognized by a finite automaton. 

Now let R C E* be a regular language of edge sequences. I define the 
R-restricted forward slice of s by 


(5.37) FS(s,R) I {t € N | VP(s,t) AR #0). 


In the following, I show how to compute FS(s, R) using a data-flow analysis 
instance. For this, let A = (Q, E, qo, Ao, QF) be a finite automaton with 


(5.38) L(A) =R. 


The idea is that the information computed at each node consists of the 
set of states in Q that are reachable during a run of A. Consequently, the 
transfer functions are defined by A. Before I define this data-flow analysis 
instance, I need some helping notions and observations. Firstly, I observe 
that for each e € E, the function AA. A (e, A) is monotone: If A C B, then 
A(e,A) < A (e, B). Secondly, for a complete lattice L and a set X CL —>mon L 
of monotone functions on X, I define cl(X) < L yon L as the least (with 
respect to set inclusion) subset Y of L >on L that (a) contains X, (b) is a 
complete lattice and (c) is closed under function composition. It is easy to 
see that c/(X) is unique and always exists. 

Now we are ready to define the data-flow analysis instance. 
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(5.39) L=22 
(5.40) F =cl({AA. A(e, A) : 22 > 22 |e € E} 
(5.41) fe = AA.A(e, A) : 22 — 22 


Theorem 5.46. For every s € N, we have 
(5.42) FS(s,R) = {te N | MOVP(s,t)({qo}) N QF #0} 


Proof. Lets € N. Firstly, by induction on n € E*, it can easily be shown 
that 


(5.43) VneE*VACQ. fn(A) = A(n,A). 


Secondly, we observe that 


(5.44) MOVP(s,t)({g0!) = |) frla). 
neVP(s,t) 


This follows from the definition of the given data-flow framework instance 

and the definition of MOVP. 

From (5.43) and (5.44), we can derive the claimed set equality. 

tEeFS(s,R) — > VP(s,t)NR#0 { definition } 

> IneVP(st).neR { rewriting } 
> Ane VP(s,t). A(7,{qo}) NQF #0 { (5.38) } 
> Ane VP(s,t). fr({qo}) NQF #0 { (5.43) } 
> MOVP(s,t)({go}) NQF #0 { (5.44) } 


5.4.5.1 Barrier Slicing 


A simple yet important special case of language-restricted slices is barrier 
slicing. Barrier slicing was introduced for PDGs by Krinke [111] as a means 
to make slicing more focussed. The idea is to introduce a barrier, i.e. a set 
B of nodes that is not to be passed. In the following, I demonstrate that 
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barrier slicing can be expressed as a regular language-restricted reachability 
analysis instance on interprocedural graphs. 

Given an interprocedural graph G = (N, Ejntra, Ecait, Eret, P,®) (e.g., a 
program dependence graph), the (backwards) barrier slice of t € N with 
respect to B is defined to be the set 


(5.45) BBS(t, B) a {s € N | In € VP(s,t).nodes(n)NB=B). 


Analogously, the forward barrier slice can be defined as 


d 
(5.46) FBS(s,B) =, {t€ N | In € VP(s,t).nodes(n)NB=M. 
The property of being a sequence from E* that avoids nodes from B can be 
expressed as the language 


d : ; 
(5.47)  A(B) fl {n € E* | Vie range(n). sre(n') € BA tgt(n') € B}. 

It can easily be seen that A(B) is regular. Hence FBS(s,B) and BBS(t, B) 
can both be determined using a regular language-restricted reachability 
analysis. 


5.4.5.2 Explicit Information Flow 


As asecond example for regular language restricted reachability analysis, I 
want to consider a heuristic property of slices that I call explicit information 
flow. This property is based on the observation that static helper analyses 
may cause the insertion of spurious control dependencies. Such control 
dependencies can easily lead to program dependence graphs in which 
everything that happens after some critical statement is control-dependent 
on this statement, solely because of the fact that this statement may fail 
due to an exception that could not be ruled out. 

As an example, consider Figure 5.5b. The array access does not fail and 
hence the program should be secure. But with a static analysis that is too 
imprecise to prove this, the resulting PDG contains a control dependency 
between the array access and the print statement. Moreover, whether the 
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1 int h = inputPIN(); 1 int h = inputPIN(); 
2 int x; 2 

3 if (h > 42) { 3 if (h > 42) { 

4 arrli] = 17; 4 arrli] = 17; 

5 x = 17; 5 

6 } 6 } 

7 print(x); 7 print(”OK”); 


(a) (b) 


Figure 5.5: Analysis precision and control dependencies — assume that arr # null 
and 0 < i < arr.length 


array access happens depends on the secret value. Hence, in this PDG, 
line 1 is connected to 7. 

In contrast, the PDG of Figure 5.5a contains a path from the secret source 
to the public sink, even if a static analysis could prove that the array access 
never fails. The path has the property that it ends in a data dependency, 
where as the Figure 5.5b does not. 

Explicit information flow only considers PDG paths that end in a data 
dependency. This way, PDG paths such as the one in Figure 5.5b are 
ignored, whereas the path in Figure 5.5a is covered. 

We also can ignore the path in Figure 5.5b by simply ignoring all control 
dependencies (like we did in one variant of the SHRIFT approach in 
section 4.7), but then we would also ignore the path in Figure 5.5a that is 
in a sense more direct. 

I consider explicit information flow as an example for a helper analysis 
for the further analysis of a PDG’s valid paths. The setting that I have in 
mind is that a PDG-based information flow control tool like Joana fails to 
verify a given information flow requirement and the analyst tries to find 
out why. If Joana succeeds to verify the requirement with restriction to 
explicit information flow, then this may indicate that Joana’s exception 
analysis is too imprecise. 

In the following, I formally describe explicit information flow as a data-flow 
analysis framework instance. 

Given a program dependence graph G = (N, Ejntra, Ecat, Eret, P, ®), I de- 
compose E into E = DD UCD, where DD is the set of all data dependencies 
and CD is the set of all control dependencies. Then, the explicit information 
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e € DD 
e € CD 


Figure 5.6: A finite automaton for explicit information flow analysis - P(e) is short 
for {e € E| P(e)}. 


flow (forward) slice of s € N consists of all nodes t such that at least one valid 
path from s to ¢ ends in a data dependency: 


EIF(s) “! {t € N | VP(s,t) NE"DD* #8). 


As E*DD* isa regular language, EIF is an instance of (5.37): 


EIF(s) = FS(s,E"DD*). 


Figure 5.6 shows a finite automaton that recognizes E*DD*. 


5.4.6 Hammer’s Approach to IFC 


In this section, I want to take a closer look at Hammer’s PDG-based 
approach to IFC [86]. 

Hammer uses a finite lattice (L, <), where the levels! € L are confidentiality 
levels; x < y means that y is as confidential as or more confidential than x. 
Partial functions P and R are used to annotate sources and sinks. Sources 
have a provided level P(n) whereas sinks have required level R(n). For now, 
we assume that dom(P) A dom(R) = 0. 

P and R are expanded to all nodes by defining 


P(n) ifn €dom(P) 
Ï otherwise 


(5.48) P’(n) = | 


(5.49) R’'(n) = fe ifn € dom(R) 


T otherwise 
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Intuitively, information leaving n has confidentiality level at least P(n) and 
information entering n has at most confidentiality level R(n). The goal is to 
propagate the confidentiality levels along the paths of G, or, respectively, 
whether such a propagation is possible without contradiction. 

The following monotone constraint system (compare [86, (4.7) on p. 102]) 
describes a function S : N — L that propagates confidentiality levels 
from dom(P). Solutions of Constraint System 5.1 can be considered to 
conservatively describe the information flows of the given program with 
respect to the confidentiality specification given by P. 


Constraint System 5.1. 


x € dom(P) YOcKk x ¢ dom(P) yYox 
S(x) > S(y) U P(x) S(x) 2 S(y) 


To be able to assess whether the given program is secure with respect to 
the complete security specification (P, R), Hammer introduces the notion 
of maintaining confidentiality. For this, he states a further set of constraints 
([86, (4.8) on p. 102]): 


(5.50) Yx € dom(R). S(x) < R(x). 


For G to maintain confidentiality, Hammer requires that Constraint Sys- 
tem 5.1 and (5.50) are simultaneously satisfied ( [86, Definition 4.1]). Note 
that the joint constraint system consisting of Constraint System 5.1 and 
Equation 5.50 is not monotone: Constraint System 5.1 and (5.50) use < in 
different directions. 

However, whether G maintains confidentiality can be checked by looking 
at the least solution S of the monotone constraint system Constraint 
System 5.1. 


Lemma 5.47. The following two statements are equivalent: 
1. G maintains confidentiality. 


2. The least solution S of Constraint System 5.1 satisfies (5.50) . 
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Proof. Since S is a solution of Constraint System 5.1, it is clear that G 
maintains confidentiality if S also satisfies (5.50). 

For the converse direction, assume that G maintains confidentiality. Then 
there is a function S : N —> L that satisfies both (5.1) and (5.50). Now, 
consider the least solution S of (5.1). We have to show that S satisfies (5.50). 
So let x € dom(R). Then S(x) < R(x). Moreover, since S is a solution of 
(5.1) and S is the least solution of (5.1), we have S(x) < S(x). Together, it 
follows that S(x) < R(x), as desired. m) 


Hammer does not state this directly, but suggests that he aims for the 
least solution of Constraint System 5.1 by stating that “Equation (4.11) is 
satisfied in the most precise way, and hence the risk that equation (4.8) is 
violated is minimized, if the inequality for S turns into equality”? [86, 
p- 103] and later referring to the solution as least fixed-point (e.g. [86, 
Theorem 4.2]). 

The simple approach showed so far is conservative but not precise: In fact, 
Constraint System 5.1 propagates provided levels along arbitrary paths 
and not only along valid paths. 

Hammer describes a slicing-based check that aims to solve this precision 
problem. A PDG G is said to ensure non-interference with respect to R and 
P, if 


vneN. | | P’(m)<R'(n) 
meBS(n) 


This amounts to computing 
(5.51) S(n)= | | P(m) 


and checking that Vn. S(n) < R’(n). 

As Hammer also notices, (5.51) can be computed using data-flow analysis. 
In my notation, an appropriate data-flow analysis instance is given by the 
following ingredients. 


30Equation (4.11) is a simplified version of Equation (4.7) in [86] or Constraint System 5.1, 
respectively. 
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1. Lis the security lattice 
= {Ax.xUl|leL} 


3. p:e fe is defined by 


(5.52) fol) =! xu P’(sre(e)) UP’ (tgt(e)) 

Then 

(5.53) fr(x)=xu || P(x) 
nenodes(r) 

and 

(5.54) MOVP(s,t)(x u [| | P’(n 


neVP(s,t) nenodes(r) 


Hammer provides an algorithm [86, Algorithm 7] to compute (5.51). 
Specifically, this algorithm generates an appropriate subset of Constraint 
System 5.1. (5.51) then turns out to be a solution of that system and can be 
checked against an appropriate set of R constraints that is also generated 
by the algorithm [86, Theorem 4.2]. 

Now I show how (5.51) can be extracted from (5.54). 

For this, Inote that 


(5.55) BS(m) = {m} U y y nodes(r). 
neN neVP(n,m) 
This enables me to re-write (5.51) as follows. 


s(n)= | | P’m) { (5.51) } 


meBS(n) 


(aul | || | | P(n) { (5.55) } 


leN neVP(],n) menodes(r) 
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= | | [o U | P e) { re-writing } 
(7) 


leN neVP(ln) menodes 
= | |] AP) { (5.53) } 
leN neVP(I],n) 


= | | fr | (P’(n)) { re-writing } 


leN neVP(I,n) 


| |move«, ») (P’(n)). { Def. of MOVP } 
leN 


Note that (5.51) does not define a solution to Constraint System 5.1, as 
Constraint System 5.1 is too simplistic, hence demands too much. Hammer 
proposes an algorithm based on two-phase slicing that generates a sub- 
system of Constraint System 5.1 for which (5.51) indeed is a solution and 
which still adequately describes the property of maintaining confidentiality. 


5.4.6.1 IFC With Declassification 


Hammer also supports a form of where-declassification, i.e. the specification 
of points in the program where confidential information is transformed 
into benign information which is allowed to be made available to lower 
observers. For this, he introduces a set DC N of declassification nodes. If 
information enters a declassification node d € D with a level of at most r, 
then d downgrades it (e.g. by sanitizing or removing classified information) 
to level p <r. 

A declassification node has both a required and a provided level (cf. [86, 
(4.18)]): 


(5.56) xeD = > (xedom(P)Ndom(R)) A R(x) = P(x) 
Hammer then adapts Constraint System 5.1 and (5.50) to also support 


declassification nodes (cf. [86, (4.19)]). This leads to the following constraint 
system. 
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Constraint System 5.2. 


xeD YocX x¢D YocKk 
S(x) > P(x) S(x) > S(y) UP’ (x) 


The check (5.50) is adapted accordingly (cf. [86, (4.20)]): 


(5.57) Yx € dom(R) \ D. S(x) < R(x) AVxeD. | | S(y) < R(x). 
YG 


The approach is now just like the in the case without declassification: The 
given program is considered secure if and only if the least solution S of 
Constraint System 5.2 satisfies Equation 5.57. Hammer’s Algorithm 7 
is also able to handle declassification nodes and generates appropriate 
subsets of Constraint System 5.2 and (5.57) that can be used to compute 
and check a solution (cf. [86, Theorem 4.6]). 

In the following, I show how (5.57) can be expressed using a data-flow 
analysis instance. 

The complete lattices L and F stay the same as in the non-declassification 
case, only the transfer functions need to be adapted. Note that Hammer 
does not give a solution representation for the declassification case like 
(5.51), so that I have to extract the transfer function from Constraint 
System 5.2. The definition of fe particularly accounts for the case that both 
src(e) and tgt(e) may be declassification nodes. 


P Ax. x U P’ (src(e)) U P’ (tgt(e)) if src(e) € DAtgt(e) ED 
6.58) f] Ax. P(tgt(e)) if tgt(e) € D 
Ax. P(src(e)) if src(e) € DA tgt(e) ¢ D 


Next, I want to consider fr more concretely: In the case that 7 contains no 
declassification nodes, it is easy to see that 


(5.59) fa = AX. XU | P’(n). 


nénodes(rt) 
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Hence, for D = Q, (5.59) is compatible with the declassification-less instance 
defined in (5.52). 

To describe fr if n contains declassification nodes, I need some additional 
notations. First of all, I call an edge e such that src(e) € D or tgt(e) € D 
a declassification edge. For n € Pathsc(s,t) such that nodes(m) ND + Ø, I 
define lastp (7) € range(r) as the greatest i such that 77! is a declassification 


d 
edge and q(7) = nzlastp(R), the suffix of n that starts with the last declas- 
def 


sification edge occurring in 7, and p(n) = n“lastp(r) as the corresponding 
prefix. 

With the help of q(7z), I can show that fr discards all provided levels up to 
the last declassification node in q(n). 


Theorem 5.48. Ifnodes(n)ND + 0, fr can be characterized as follows: 


src(q(m)°) € D 


5.60 a = AX. P’ 

2 Atgt(q(m)°) € D R i „ul, K 

(5.61) tgt(q(m)°)€D = fa=Ax | | P(tgt(e)) 
eeedges(r) 


Proof. First, we observe that it is enough to show (5.60) and (5.61) for f, (x): 


sre(q(n)" <) € D 
(5.62) => fyn) = Àx. P' (n) 
Atgt(q(n))e@D I Be 
(5.63) tgt(q(m)°)€D => fyny=Ax. | | — P’(tgt(e)) 
eeedges(q(r)) 


The reason is that the right-hand sides of (5.62) and (5.63) are constant 
functions, i.e. if (5.62) and (5.63) hold, then we have 


(5.64) Yx, y EL. Fan) (&) = faln) (y) 
Now assume that (5.62) and (5.63) are true and let x € L. Then we have 


falx) = honam) { definition of p(r), q(r) } 
=. fim pr) (x)) { properties of fx } 
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= a(n) (x). { (5.64) } 


It remains to show (5.62) and (5.63). For this, we consider q(7) more 
closely: It is not empty and consists of exactly one declassification edge 
at the beginning, i.e. g(r)? is a declassification edge and q(r)” contains 
no declassification edges and hence no declassification nodes. Hence, for 
every x € L, we have 


San) (x) = faln) e-q) > (x) { definition } 
= fam Gam (*)) { properties of fx } 
=f [|] Pa 1659} 
nenodes(q(m)?9) 


Now, (5.62) and (5.63) follow from the different cases in the definition 
(5.58) of Ian) Because g(r)? is a declassification edge, we do not need 


to consider first case in (5.58). For the remaining two cases, we argue as 
follows: 


o If src(q(m)°) € DA tgt(q(m)°) € D, then we have 


fymo(x)u || Pro 


nenodes(q(1)>°) 
=P'(sre(q(n)°))u || (mn) 1658) 
nenodes(q(m)?°) 
= | P' (n). { definition of nodes } 
nénodes(q(7)) 


e If tgt(q(7)) € D, then we have 


mau || Pe) 


nenodes(q(m)?°) 
=P'(tgt(g(n)))U || P(n) {definition } 
nenodes(g(r)>P) 
= || Pte). { (x) } 
ecedges(q(n)) 
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To conclude the proof, we need to justify the last step (x). Its validity 
can easily be seen in the case that q(7)”° = e. For q(m)?° + e, we 
note 


nodes(q(m)*°) = {tgt(e) | e € edges(q(m))}. 


Moreover, since g(rt) is a path, we have 


tgt(q(r)°) = sre((q(n)>°) ) € nodes(q(n)”°). 


Together, this implies 


nodes(q(r)”?) = tgt(q(7)°) U {tgt(e) | e € edges(q(m))}. 


5.4.7 Least Distances 


The problem of computing least distances can also be expressed as the 
instance of a data-flow framework. Computing least distances can be 
considered a flexible tool to help in PDG-based IFC analysis. By comput- 
ing least distances, useful information about the valid paths of a given 
interprocedural graph can be generated. Such information could be used 
to classify the set of valid paths between two nodes, e.g. with respect to the 
kinds of dependencies. For example, a least distances analysis could be 
used to compute the minimum number of control dependencies between 
two nodes s and t. If this number is 0, then s and t are connected via a 
chain of data dependencies and the higher the number, the more control 
dependencies are required to transmit information between s and t. 

In the following, I describe the data-flow framework for least distances in 
the simplest case that every edge is given a weight of 1. 

Consider the set N U {oo}, partially ordered by Eœ, which extends the 
natural ordering > on IN such that o is the least element with respect to 
Eo. Note that, in comparison to <, E% is “upside down”. 

With respect to Eos, IN U {oo} is a complete lattice: Since every non-empty 
subset A C N has a least element with respect to <, the least upper bound 


227 


5 A Common Generalization Of Program Dependence Graphs and Control-Flow Graphs 


has the following characterization: 


ie ifA=0 
| |4= minA if AF OAOEA 
min(A—{co}) ifweA 


The space F of transfer functions can be chosen as 


F:={Ax.x+d|de No} 


As can easily be seen, all f € F are monotone, and F is closed under 
arbitrary joins and function composition. 
In the easiest setting, we give each edge the distance 1: 


ple)(x) =x+1. 


Now let G = (N, Ejntrar Ecatt Eret, P, ®) be an interprocedural graph. For a 
path x € Paths(G), fr is then the function that adds the length of 7 to its 
argument. Hence, if VP(s,t) #0, MOVP(s,t) adds the minimal length of 
a path between s and t to its argument. Generally, MOVP(s,t) € Fa can be 


characterized as follows?!: 


MOR k +minfal |m VP(s,t)} if VP(s,t) #0 
x otherwise 

Note that although there are large similarities, the least-distances-along- 
valid-paths problem cannot be cast as an instance of the traditional 
shortest-paths problem on directed graphs for which there are estab- 
lished approaches [56]. Knuth [108] considered a version of the least- 
distances-problem that can be considered similar to our setting. Traditional 
approaches compute the length of a shortest arbitrary path in the given 
graph, while we are interested in the length of a shortest valid path. A 


31 As I pointed out in section 5.3, I always adjoin a the set F of transfer functions with an 
additional element &. For this particular instance, this is technically not necessary, because 
Ax.co has all the properties that I assume about m. 
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Figure 5.7: A small example with ® = {(e1,e2), (e3,e4)} which shows that the 
shortest valid path may differ from the shortest arbitrary path. (b) 
shows the shortest arbitrary path, which has length 3 and is invalid, (c) 
shows the shortest valid path which has length 7. 


simple example of this restriction is shown in Figure 5.7. In this example, 
the shortest arbitrary path between s and t does not respect the corres- 
pondence relation ¢ and therefore is invalid. The shortest valid path is 
significantly longer because both of its sections that enter p’ have to leave 
it through the corresponding return edge. 

It is also worth noting that distance calculations on PDGs have been 
considered before, e.g. by Krinke [110]. Consider a PDG with summary 
edges. If every edge, including summary edges, is annotated with a weight, 
a two-phase approach can be used to compute least weights along paths 
including summary edges. In his description, Krinke [110] does not specify 
the weight that he assigns to summary edges, but I suspect that he uses a 
weight of 1. Hence, he consequently under-estimates the length of same- 
level paths and, in the terminology of the data-flow framework instance 
discussed in this section, computes an over-approximation®? of MOVP. 
Hence, Krinke’s approach is correct and more precise than computing least 
distances w.r.t. arbitrary paths, but it is imprecise w.r.t. MOVP. 

The generalized algorithms that I present in chapter 7 can be used to (a) 
annotate each summary edge between to nodes ng and n4 with the length of 


32Remember that the partial order is upside down. 
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a shortest same-level path between ng and nı and then to (b) precisely compute 
the least distances along valid paths. 
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People asking questions, lost in confusion. 
Well, I tell them there’s no problem, 

only solutions. 

JoHN LENNON 


Two Approaches to 
Abstract Data-Flow Analysis 
on Interprocedural Graphs 


In this chapter, I describe versions of the functional approach and the call- 
string approach to interprocedural data-flow analysis for my generalized 
data-flow frameworks. For classical data-flow frameworks, I already 
described these two approaches in chapter 3. The two approaches use dif- 
ferent ideas to tackle a fundamental problem that arises in interprocedural 
data-flow analysis, namely that arbitrary paths in interprocedural graphs 
do not necessarily reflect valid calling and returning behavior of actual 
program executions. In chapter 3, I already described this problem: An 
arbitrary path may contain returns that do not return to the call site from 
which the call started. 

The idea of the functional approach is to first solve a helper problem whose 
solution describes the data-flows along same-level paths. In a second step, 
this helper solution is then used to describe the data-flows along realizable 
paths. 

In contrast, the call-string approach simulates the call stack usage of paths 
in order to rule out paths with invalid calling and returning behavior. 
Sharir and Pnueli [154] showed that both approaches lead to correct 
approximations of MODESC in interprocedural control-flow graphs and, 
for distributive frameworks, can compute MODESC exactly. However, 
the unrestricted call-string approach uses stacks of unlimited height and 
therefore does not lead to effectively solvable constraint systems. This is 
why one usually uses k-bounded stacks, whose height is not greater than k 
items, and which lead to a correct approximation. 
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In this chapter, I generalize these results. I describe versions of the 
functional approach and the call string approach that are based on inter- 
procedural graphs, the general graph model that I introduced in chapter 5. 
Interprocedural graphs cover both interprocedural control-flow graphs 
and program dependence graphs. Furthermore, I show that both the 
functional approach and the unrestricted call-string approach enjoy the 
same properties as in the classical case. Moreover, for the call-string 
approach, I introduce stack abstractions, a general technique that makes it 
possible to obtain correct approximations to the call-string approach. I 
demonstrate the applicability of stack abstractions by using them to show 
that my version of the call-string approach is correct for k-bounded stacks. 
The following sections are structured as follows. In section 6.1, I make 
some preparations and fixtures. After that, section 6.2 considers the 
generalized functional approach. Lastly, I describe my version of the 
call-string approach in section 6.3. 


6.1 Preliminaries 


In section 6.2 and section 6.3, I will specify several constraint systems 
and examine the properties of their solutions. This section makes several 
necessary preparations. Subsection 6.1.1 specifies the expressions that 
appear in the constraint systems of this chapter and makes clear their se- 
mantics. Subsequently, subsection 6.1.1 introduces correctness and precision 
as quality criteria of solutions to constraint systems with respect to a given 
MOP function. 

For this chapter, I fix a data-flow analysis framework instance F = 
(G, L, Fg, p) in the sense of section 5.3. 


6.1.1 Syntax and Semantics 


First, I have to make clear my assumptions about the expressions and 
their interpretations from which the constraint systems in this and the next 
chapter are formed. The set of variables X will always become clear from 
context and is left unspecified for the moment. Moreover, I assume that 
the set 7 of function symbols contains 


e a unary symbol f for every f € Fg and 
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e abinary symbol o. 


In order to provide the semantics functional [-] : Expr(f, X) — Fa, I need 
to specify the interpretation function a that assigns every function symbol 
a function on with the appropriate number of inputs from Fg. My obvious 
choice for a is 


a(f) = f forall f € Fr 


fog iff,geF 
K iff=mavVg=m 


alo)(f,8) -| 


6.1.2 Correctness and Precision of Solutions 


The constraint systems that I will present in the following sections are 
supposed to approximate MOP for respective path sets P. Definition 6.1 
provides the main criteria for assessing the quality of a given function 
relative to MOP. 


Definition 6.1. Let P < Paths(G) be a set of paths, EC N XN a set of node 
pairs and A: N XN > Fa be a function. Then A is called 


1. (P, E)-domain-correct if it yields a defined value for every (s,t) € E that is 
connected by a path in P: 


Ys,t E€ N. (s,t) € EA Pathsc(s,t) AP #0 = A(s,t) An. 


2. (P, E)-domain-precise if it does not yield a defined value for (s,t) € E that is 
not connected by a path in P: 


Ys,tEN. (s,t) €EAA(s,t) #B = Pathsc(s,t) NP +0. 
3. (P, E)-correct if it over-approximates MOP on E: 


Vs,t EN. (s,t)€ E = > A(s,t) > | fr 
nEPathsg(s,t) OP 


4. (P, E)-precise if it does not exceed MOP on E: 


Vs,teN.(st)eE => A(s,t) < | fr: 
nePathsc (s,t)NP 
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I call A just P-correct/precise, if it has the corresponding property with respect 
to (P,N XN). 


Definition 6.1 is more general than needed in chapter 6: Specifically, 
Definition 6.1 also takes solutions into account that are + & only for a 
part of Nx N. I will need this in chapter 7, which is concerned with 
computing partial solutions. As my solutions not only give analysis values 
but also communicate whether there is a value or not, an additional item of 
comparison is the domain. Hence, Definition 6.1 also incorporates notions 
that enable to compare the domains of solutions to the domains of objective 
functions. 

It is easy to see that P-correctness of a given function A can be verified by 
simply showing that every fr is incorporated in A. This will be my main 
tool to prove correctness, so I note it here. 


Remark 6.2. A function A: NX N > Fa is P-correct if and only if 
Vs,t € N. Yr € Pathsc(s,t). (s,t)e EAT EP => fr < A(s,t). 


In order to show precision, I will use the argument that is formalized by 
Remark 6.3. 


Remark 6.3. Let C bea set of constraints over variables N x Nand P C Paths(G). 
Then If p(Fe) is P-precise if MOP is a solution of C. 


6.2 The Functional Approach 


This section describes the functional approach to solve a given inter- 
procedural data-flow framework instance. 

The pattern of the functional approach is analogous to the successive 
construction of the same-level, the ascending, the descending and finally 
the valid paths that we saw in chapter 5. 

Each step considers a set P of paths (where P = SL, ASC, DESC, VP in 
this order) and uses the results from earlier steps to specify a monotone 
constraint system Cp, whose solutions 


Xp :NXN > Fa 


are P-correct, i.e. are over-approximations of MOP. For simplicity, I say 
that both Cp and its solutions correctly describe the data transfer along paths 
from P. 
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6.2.1 Constraint Systems 


The constraint systems themselves are constructed in a fashion that is 
very similar to the inductive definitions of the corresponding path sets. 
First, I introduce a constraint system to describe the data transfer along 
same-level paths. 


Constraint System 6.1. 
XsL :NXN > Fa 
is a same-level-solution if it satisfies all constraints from the following system: 


(sL-soL-(1)) Xs (5,8) > id 


tt e € Eintra 
Xsz(s,t) = feo Xsr(s,t’) 


(sL-soL-(m)) 


Ecall eret 
n > no n >t (ecall, eret) € ® 


Xs (,t) = feret © Xsz(N0,11) © fen? Xsı(s,n) 


For the sake of presentation, my notation of Constraint System 6.1 and 
later constraint systems is somewhat sloppy. For one, I use the actual 
functions from F and function composition where I actually mean their 
corresponding function symbols. Also note that the Xs; (_,_) actually 
denote corresponding variables. Thirdly, I want to point out that the 
clauses of Constraint System 6.1 — and most other constraint systems 
shown in this thesis — are to be understood as rules that specify when to 
include a constraint to the system. This is why in the following, I will refer 
to these clauses as rules. 

All in all, st-sox-(1m) reads: 


(sL-soL-(11)) 


ecall eret ; p 
Foralln > ng and n > t with (eall, eret) € ®, the system contains 
the constraint Xsz (s,t) > fe, Xst(s,1)°fe__,OXsz (Ss, 1). 


call — 


In the following, I want explain the intuition behind Constraint System 6.1. 
It is supposed to specify a function Xsz that correctly describes the data 
transfer along same-level paths. More concretely, Xs; (s, t) shall correctly 


235 


6 Two Approaches to Abstract Data-Flow Analysis on Interprocedural Graphs 


approximate MOSL(s, t), i.e. incorporate all path functions fr along same- 
level paths 7 from s to t. Hence, it is natural to construct Constraint 
System 6.1 in correspondence with the inductive definition of SL. 

To illustrate this, I consider st-sox-(111) more closely. Let (ecall, eret) € ® 


e 
with n no and nı “ 4. In order to describe the data transfer along 
same-level paths from s to t, we have to ensure that 


(6.1) XsL (s, t) 2 Soret 9 tr’ 9 Fecal 9 fr 


for all n’ € SL(s,n) and all n” € SL(ng,nı). 

Suppose that Xs; (no, n1 ) describes the data transfer along same-level paths 
from ng to nı and that Xs; (s, n) describes the data transfer along same-level 
paths from s to n. Then (6.1) can be satisfied for all n’ € SL(s,n) and all 
n” € SL(no, ny) if 


(6.2) XsL(s,t) = fert © XSL (no n1) © fern ° XSL(S, n). 


Rule st-soL-(111) specifies that Constraint System 6.1 contains a constraint 


of the form (6.2) for all (esai, eret) € ® with n = no and nı “call + The three 


rules together cover all possibilities to construct a same-level path. 

Next I use solutions Xs; of Constraint System 6.1 to describe the data- 
flow along ascending paths. The construction principle behind these two 
constraint systems is the same as for Constraint System 6.1 and their 
intuition can be explained similarly. 


Constraint System 6.2. Let Xs, : N X N — Fa be a function. Then 
XASC :NxN- Fa 


is an ascending-path-solution (relative to X; ) if it satisfies all constraints from 
the following system: 
(Asc-soL-(1)) 


tot e € Eintra U Eret 


(asc-sor-(11)) Xascls,t) > feo Xasc(s,t’) 


call eret 
non n >t (€cait, Eret) c Xs (no, nı) + K 


Xasc(s,t) = feret © XsL (no, 11) © fe. © XASc(S, n) 


(asc-soL-(111)) 
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At this point, I want to highlight yet another subtlety in Constraint 
System 6.2 that applies to all constraint systems in this thesis that make use 
of some helper functions. Unlike in Constraint System 6.1, Xs, (9,11) in 
the lower part of asc-soL-(111) is not a variable but a constant. In particular, 
if Xs (no n1) = f € F, I actually mean f when I write Xs,(ng,nı) ina 
constraint. Furthermore, it is also worth mentioning that since the upper 
part of asc-sox-(111) is not part of the actual constraint but rather specifies 
when to include the constraint, Xs; (no, n1) in the upper part is used as 
value. 

In particular, no constraint is contained in the same situation but 
Xsr(no,nı) = ®. For the solutions of Constraint System 6.2, it is not 
important whether Xsz (no, n1) # & is demanded or not for a constraint to 
be present. However, in chapter 7 I will make statements about variables 
on the left-hand sides of constraints and I need this assumption in order 
for these statements to make sense. 

The data transfer along descending paths is described by Constraint 
System 6.3, which is completely analogous to Constraint System 6.2. 


Constraint System 6.3. Let Xs, : N X N > Fa be a function. Then 
XDESC :NXN > Fa 


is a descending-path-solution (relative to Xs) if it satisfies all constraints from 
the following system: 
(DESC-soL-(1)) 


Xpesc(s,s) 2 id 
r + t e € Eintra U Ecall 


(DESC-SOL-{1I)) ——————__————_ 
Xpesc(s,t) 2 fe ° Xpesc(s,t’) 


e e 
n l no ny ey (€catts eret) € & Xs (no, nı) #R 


Xpesc (8,8) = feret °Xsı(No,N1) fen °XDeEsc (s, 1) 


(DESC-soL-(111)) 


Finally, like valid paths are constructed from the ascending and descending 
paths, the data transfer along valid paths are described using solutions of 
Constraint System 6.2 and Constraint System 6.3. This directly leads to 
Constraint System 6.4. 
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Constraint System 6.4. Let 

XASC :NXN > Fa 
and 

XDESC :NXN > Fa 


be two functions. Then 
Xyp: NxN > Fr 


is a valid-path-solution (relative to Xasc and Xpgsc) if it satisfies all constraints 
from the following system: 
Xasc(s,n) #8  Xpesc(n,t) + 


Xyp(s,t) = Xpesc(n,t) o Xasc(s,n) 


(VALID-SOL) 


6.2.2 Correctness and Precision 


In the following, I show important properties of the solutions of the 
constraint systems I just introduced. First, I show that the constraint 
systems indeed meet their purpose, i.e. that their solutions correctly 
describe the data transfer along the corresponding paths. Given the 
construction principle behind the constraint system that I described at the 
beginning of this section, this should be no surprise. 

Before I start my actual proofs, I state two elementary properties about F 
that I will need later at various places. 


Remark 6.4. Function composition is monotone on F, both in the left and in the 
right argument: 


(6.3) Vfi- 81 fo 82 € Ff. S fo 481 S82 => fri S fr° 82 
Proof. This is an easy calculation. m| 


Remark 6.5. The function 

(6.4) | |22 >F 

is monotone in the following sense: 

(6.5) vaBe2.acB— | |As| |B. 


238 


6.2 The Functional Approach 


I proceed with showing that solutions of Constraint System 6.1 are SL- 
correct. 


Theorem 6.6. Every same-level solution X}, is SL-correct. 


Proof. We show 
fn S Xsı(s,t) 


by induction on the definition of n € SL(s,t). 


1. For n = e, we have fn = id < Xs,(s,s) by definition and constraint 
SL-SOL-(I). 


2. Letn = n’ -e with n’ € SL(s,t’) and t À t. By induction hypothesis 
we know 


(WHintra) ta s XsL (s, r) 
Hence 
fn = feo fw { by definition } 
< fe o Xs, (s, t) { by (THintra), (6-3) } 
< Xs1(s,t) { by constraint st-sox-(11) } 


call 
3. Let n = n + cai T” -ere with n’ € SL(s,n),n © no, n” € SL(ng,n), 


nı “3 tand (Ecall, €ret) € ®. By induction hypothesis we know 


(THg)) fm < Xsx(s,t") A far < Xs,(no,nı) 
Hence 
fr = Jeret o far o fecal o fw {by definition } 
< Seret = Xs (no na) 9 Seit 9 Xsı (s, n) { (TH), (6.3) } 
< Xsy(s,t) { by st-sox-(11) } 
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Next, I consider the ascending paths. Theorem 6.7 states that solutions of 
Constraint System 6.2 are ASC-correct, provided that Constraint System 6.2 
is defined with respect to an SL-correct function Xs;. According to 
Theorem 6.6, Xs, may be obtained as a solution of Constraint System 6.1, 
but could also be given in any other way - as long as it is SL-correct. 


Theorem 6.7. If Xs; is SL-correct and X asc is an ascending-path solution 
relative to Xsr, then X asc is ASC-correct: 


Xasc > MOASC 


Proof. We show 
Yr € ASC(s,t). fa < Xasc(s,t) 


by induction on 7 € ASC. The cases ASC-SEQempty and ASC-SEQasc are very 
similar to the corresponding cases in the proof of Theorem 6.6, so we only 
consider ASC-SEQg). 


e 
Let n = n’ -eoll T” -eret Where n’ € ASC(s, n), no, n” € SL(ng,nı),nı Bt 
and (ecall,Eret) € ®. By assumption, we know 


(Ass,)) fa” < XsL(no 11), 
and, by induction hypothesis, 
(Hs) fw < Xasc(s,n). 


Furthermore, we know that fw + 8 by (5.14) and (5.15). By (Ass,)), this 
means that also Xs; (no, n1) # &. Hence, using (6.3), 


fr = Seret o fn” o fecal o fw { definition } 
< Feret o XsL (no, ny) Feng o XASC (s, n) { (Ass,), Hs) } 
< Xasc(s,t). {by asc-soL-(111) } 


oO 


Similar to Theorem 6.7, Theorem 6.8 states that solutions of Constraint 
System 6.3 are DESC-correct, provided that Constraint System 6.3 is defined 
with respect to an SL-correct function Xs;. The proof is omitted as it is 
completely analogous to the proof of Theorem 6.7. 
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Theorem 6.8. If Xsz is SL-correct and Xpgsc is a descending-path solution 
relative to Xs, then Xpgsc is DESC-correct. 


Finally, Theorem 6.9 states that any solution of Constraint System 6.4 
with respect to an ASC-correct function X4sc and a DESC-correct function 
XDESC is VP-correct. 


Theorem 6.9. Let X4sc be a ASC-correct, Xpgsc be DESC-correct and Xyp be 
a valid-path solution relative to Xasc and Xpgsc. Then Xyp is VP-correct. 


Proof. We show 
Vn € VP(s,t). fa <Xvp. 


by induction on n € VP(s,t). 
So letn € N, m1 € ASC(s,n) and nz € DESC(n,t). By assumption, we have 


fry < Xasc(s,n) A fro < Xpesc(n,t) 


Furthermore, we know that fr, € Fand fr, € F using (5.14) and (5.15). 
Hence we can conclude 


fr = fm ° fry { definition } 
< Xpesc(n,t) oXAsc(s,n) {by assumption, monotonicity of o } 
< Xyp { by constraint vALID-soL. } 


o 


Next, I want to consider the question under which circumstances the 
constraint systems not only correctly describe the data transfer along their 
corresponding path set P but are also P-precise. For classical interproce- 
dural data-flow analysis, this is the case if they are universally distributive 
[154]. Such a result can also be given for my generalized setup. 

Using the argument from Remark 6.3, it suffices to show that MOP is a 
solution of the corresponding constraint system Cp in order to guarantee 
precision of lfp(Fc,,). This is stated and proven in Theorem 6.10. 


Theorem 6.10. Assume that Fa is universally distributive. Then the following 
statements are true: 


1. MOSL is a same-level solution. 
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2. If Xs; is SL-precise, then MOASC is an ascending-path solution with respect 
to Xs. 


3. If Xs; is SL-precise, then MODESC is a descending-path solution with respect 
to Xs. 


4. If Xasc is ASC-precise and Xpgsc is DESC-precise, then MOVP is a valid- 
path solution with respect to Xasc and Xpgsc. 


Proof. 1. We show that MOSL satisfies sL-soL-(1), SL-SOL-(11) and sL-soL-(111). 


sL-soL-(1) : For every s € N, MOSL(s,s) > id is satisfied because e € 
SL(s,s). 


sr-sor-(m) : Lets € N, e € Eintra, t’ € N such that t’  t. Then we have 
SL(s,t) 2 {m -e | rn’ € SL(s,t’)} 
This means that 
MOSL(s,t) >| [fwe ln € SL(s,t’)} {(6.5)} 
=| |o fw ln’ € SL(s,#))} { def. of fr } 
= feo| fw In’ € SL(s,t’)} { fisu.d.} 
= fz o MOSL(s,t’) { def. of MOSL } 
sL-soL-(1m) : Let s € N, ec € Eca, & € Erer, and n,ng,nı € N such that 
(ec,er) <®,n S ng and ny > t. Then 
SL(s,t) 2 {711 ec Mo + €r | T1 € SL(s, n), T2 € SL(ng,nı)}. 
This means that 
MOSL(s, t) 
> | Jir, © fry © fec © fr, | T1 € SL(s,n), T2 € SL(no,nı)} 
{ (6.5), definition } 
= fer o| [Un | m2 € SL(no m )}o feco | [fr Im € SL(s,n)} 
{F is u.d. } 


= fer fe} MOSL (nọ, nı) (0) fee (0) MOSL(s, n) 
{ definition of MOSL } 
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2. We show that MOASC satisfies the constraints from Constraint Sys- 
tem 6.2 with respect to X¢7. 


ASC-SOL-(1) For every s € N, MOASC(s,s) > id is satisfied because e€ € 
ASC(s,s). 


asc-soL-(1) Let s,t,t/ € N, e € Eina UEret with t — t. Then we have 
mt’ -e € ASC(s,t) for every n’ € ASC(s,t’). Hence, 


{n’ -e| |’ € ASC(s, t’)} < ASC(s,t), 
which translates to 
| fre Im’ € ASC(s, t”)} < MOASC(s,t). 


Thus we can conclude 


MOASC (s, t) 
>| Hre ln € ASC(s,t’)} { see above } 
=| Iifeo fw Im’ € ASC(s,t")} { definition } 
= feo| fw Im’ € ASC(s,t’)} { Fy is u.d. } 
= fe o MOASC(s,#’). { definition } 


ASC-SOL-(m) Let s,t € N, ec € Eazy, er € Eret with n te no, nı A t, (€c,er) E È 
and Xs; (no, n1) # &. Then, according to the closure properties of ASC, 
we have n’ ec: n” -ep € ASC(s,t) for all n’ € ASC(s,n), n” € SL(no,nı). 
Hence we have 


{n’ -ec n” -e, | T E€ ASC(s,n), n” € SL(ng,nı)} E ASC(s,t), 
which, due to (6.3), implies that 


|h faeere, | € ASC(s,n), n” € SL(no,n1)} 


(6.6) 
<MOASC(;,t). 


We conclude as follows: 


MOASC(s, t) 
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= lese | m4 € ASC(s,t’), T2 € SL(ng,n1)} 
{ see above } 
= | J © fn, © fec © fn Inı € ASC(s, t’), T2 € SL(no, n1)} 
{ definition } 
= fe © | Vm | 72 € SL(ng,nı)} © fe. © | Jr In € ASC(s, t’)} 
{ Fx is u.d. } 
= fe, o MOSL(no, n1) © fes oMOASC(s,1) 
{ definition } 
> fe, © XsL(no, n1) © fee ° MOASC(s, n). 
{ Xs; is SL-precise, (6.5) } 


3. This is very similar to the proof of 2. 
4. For every n € N, we have 
MOVP(s,t) 
=| |U © fry | 1 € ASC(s, n), n2 € DESC(n, t)} 


{ definition } 
=| |f |71 € DESC(n,t)}0| tfr | m1 € ASC(s,n)} 
{ Fm is u.v. } 


> Xpesc(n,t) o Xasc(s,n). 
{ assumptions about X,4sc and Xpesc, (6.3) } 


6.3 The Call-String Approach 


The basic idea of the call-string approach, which I already explained in 
chapter 3, is to additionally simulate a call stack: Each time a procedure 
is called, the call site is pushed to the stack, and each time the procedure 


244 


6.3 The Call-String Approach 


returns, the call site it is supposed to return to is popped off the stack. Sharir 
and Pnueli showed for classical interprocedural data-flow analysis that the 
call string approach with unbounded stacks yields the same solution as the 
functional approach [154]. However, unbounded stacks also lead to infinite 
constraint systems and lattices that do not satisfy (ACC). This is why in 
practice, one usually uses approximate approaches such as bounded stack 
heights. 

In this section, I will give a general and formal presentation of the call- 
string approach under my more general assumptions. The general results 
of this section will be that (a) I can achieve the same result as Sharir 
and Pnueli under my more general assumptions and (b) that I provide 
a general framework from which one can derive correctness results for 
approximative call-string approaches that include but are potentially not 
limited to bounded stack heights. 

This section is divided into four subsections. In subsection 6.3.1, Iintroduce 
the abstract concept of stack spaces, which provide enough structure to 
simulate the calling behavior of interprocedural programs but are general 
enough to at least cover both unbounded and bounded stack heights. 
Given a stack space S, I then introduce the S-acceptable paths, i.e. the set 
of paths of G that exhibit valid stack usage with respect to S. Moreover, 
I define a monotone constraint system and prove a correctness and a 
precision result for solutions of this system. These results are similar to 
the corresponding results in section 6.2, but do not compare solutions to 
MOVP but to the merge over all S-acceptable paths. In order to get results 
with respect to MOVP, I need to relate the S-acceptable paths to VP for 
specific stack spaces and this is the subject of the other subsections. As a 
first step, I consider the space of unbounded stacks in subsection 6.3.2. For 
this stack space, I can indeed show that the acceptable paths coincide with 
VP. After that, in subsection 6.3.3, I describe a way that allows to transfer 
correctness results between stack spaces. For this, I introduce the concept 
of stack abstractions, which allows to relate two stack spaces using the more 
general and well-known concept of galois connection. The main result of 
subsection 6.3.3 is that if there is a stack abstraction between two stack 
spaces S and S*, then all S-acceptable paths are also S*-acceptable. Finally, 
subsection 6.3.4 gives an example of an application of this main result and 
proves that the call-string approach using the space of k-bounded stacks 
yields a correct approximation of MOVP. 
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6.3.1 Stack Spaces 


Definition 6.11 introduces stack spaces. A stack space is an abstract structure 
that provides the interface needed by an interprocedural program to 
implement procedure calls. 


Definition 6.11. A stack space over the alphabet A is a partially ordered set 
(S,<) (whose elements are called stacks) with a distinguished element e (the 
empty stack) and functions 


push: AXS >S 
pop: (S\ {e}) >S 
top: (S\{e}) > A 
such that the following conditions hold: 


(EpsMax) e is the greatest element w.r.t. <: Wo € S.o < € 
(PopMon) pop is monotone w.r.t. < . 
(PushMon) For every a € A, push(a,-) is monotone w.r.t. < . 


Pushing preserves non-emptiness: 


PushNE 
wenn Vae A. Yo € S.o +e = push(a,o) + € 
Pushed elements can be found at the top: 
(TopPush) 
Va € A. Yo € S. push(a,o) #€ = top(push(a,o)) =a 
Non-empty stacks can be expressed with push and pop: 
(NEPushPop) py P p Pr 
Vo € S.o +e = > (Ja €A. o = push(a,pop(c))) 
top is compatible with <: 
(TopVsLe) 


Y ES. e^ #EAG <o = top(o) = top(o’) 
(PopPushLe) Va €A. Vo € S. push(a,0) #€ => o < pop(push(a,o)) 


The axioms (TopPush), (NEPushPop) and (PushNE) should not be sur- 
prising as they essentially describe how a stack works. 

Additionally, stack spaces provide a partial order. The intuition behind < 
is that a stack space not necessarily provides full and precise information 
about actual call stacks but may only give partial and approximate inform- 
ation. We can use < to compare stacks with respect to the information 
they provide: Given two stacks 0,0’, o < 0’ is supposed to represent that 
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o’ does not provide more information than o. The axioms (PushMon), 
(PopMon) and (TopVsLe) specify that the main operations push, pop and 
top are compatible with <. 

A special case is the empty stack e that provides no information. This 
is formalized by (EpsMax). Finally, I want to give some explanation for 
(PopPushLe). It considers a stack o and an element a and compares o to 
the result of first pushing a to o and then popping one element off the 
top. Normally, one would expect that the result of these two subsequent 
operations should be just o. This is indeed the case for unbounded stacks 
but in general, I cannot demand this since stack spaces are supposed 
to also cover bounded stacks. For bounded stacks, which I will formally 
show in Example 6.13, there is a k > 0 such that no stack is higher than 
k. Consequently, such a stack can be full. If we push an element to a 
full stack and want to preserve the top, we simply remove the element 
at the bottom. Popping off the top element then does not yield the full 
stack but only a prefix of it. This is why (PopPushLe) only demands that 
o < pop(push(a,c)). 

The following two examples show to important stack spaces, namely the 
spaces of unbounded and k-bounded stacks, respectively. 


Example 6.12. Consider Soo = (E* y Sco, Ex, Pushoo, POPoo, top) with 


o Sco 0’ Eh ote Pre fixes(c) 
Ex ea e (empty sequence) 

pusho (e, o) = e-o 
popes(e-a) = 0 = (e-o)*! 
topæ le: 0) ee (e- 0)" 
Soo is a partial order, as can easily be verified, and So is a stack space over E qi: 
(EpsMax) e is a prefix of every symbol sequence. 
(PopMon) Ife-o’ is a prefix e’ - o, then e = e’ and o’ is a prefix of o. 
(PushMon) If o’ is a prefix of o, then e- o is a prefix of e-o’ for every e € Egy. 


(PushNE) It is clear that o + e implies a -o # e. 
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(TopPush) It is also easy to see that top» (pusho (a, 0)) = topoo(a:a) = a. 


(NEPushPop) Every non-empty sequence o can be expressed as e - 0! for some 
ee Egan: 


AA If 0,0’ are both not empty and o is a prefix of o’, then obviously 
oł = g”? 


(PopPushLe) For every o € E” „, we have popa (push(a,0)) = 0 2% 0 


call’ 


Example 6.13. For k € N, consider Sy = (E ae <k, Er, pushk, popp, topp) with 


o<go’ EF, gre Pre fixes(o) 
Ek a e (empty sequence) 
push;(e,o) 2 (e: 0)** 
pople:0) Fo 
topple- o) er 


Then Sx is a stack space over Eag: This is trivial for k = 0, so that we only 
consider the case that k > 0. <, is a partial order with greatest element ex, so that 
EpsMax is satisfied. 


(PopMon) See Example 6.12. 


(PushMon) push;(e,-) is monotone with respect to <x because it is the com- 


position of Ac. e-o and Ao. o<*, which are both monotone with respect to 
<k- 


(PushNE) Let o € EN with o + e. Then push(e,c) = (e-0)* = e- 


(TopPush) The argument from above shows in particular that 
top(push(e,o)) = 


for every o € ESE ‚ee Evatt. 


call’ 
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(NEPushPop) Let o € ES be non-empty. Then o = e-o?! for some e € 
SE = (e-071)S* = (e-popr(o))* = 


Eval. Since o € En we have o = o 


pushg(e, popx(0)): 
(TopVsLe) See Example 6.12. 


e:o 


(PopPushLe) Leto € ET We make a case distinction of whether |o| < k or 
lol =k: 
© Iflol < k, then |e-o| < k, which means that e -o = (e-o)<* = pushy(e, o). 
Hence, pop, (push,(e,o)) = popx((e: 0)**) = popx(e- 0) = o. 
e Ifjol = k, then push;(e,c) = e-oX*, so that pop, (push;(e,o)) = o 
Since o* is a prefix of o, this shows that o <; pop, (push;(a,c)). 


<k, 


In the following, I consider a fixed stack space 
S = (Ecall, S, S,E, push, pop, top) 


over E call- 

Next, I want to introduce the paths in G that exhibit an acceptable stack 
behavior with respect to S and the correspondence relation ®. For this, I 
use a function cs that takes as input an edge sequence n € E*. This function 
traverses 7 and simulates rı’s usage of calls and returns with respect to S 
and ®. Each time a call edge is encountered, cs applies the push function 
of S to the current stack. Each time a return edge is encountered, cs checks 
whether the top of the current stack corresponds to the return edge with 
respect to ®. If so, the top is popped off using the pop function of S - if 
not, cs concludes that 7 is unacceptable or invalid. 

In summary, cs returns either a call stack that is left behind by 7, e.g. 7 just 
consists of a series of call edges, then the result of cs is the stack that consists 
of these unfinished calls) or a special symbol v that signals unacceptable 
stack behavior. Occasionally, I will also call v the invalid stack. 

I extend Sand < by Y such that V is the least element with respect to < and 


(6.7) push : Eca X Sy > Sy 

(6.8) pop : (S\{e}) U {Y} > Sy 

such that 

(6.9) Vo € S. Ye € Eqn. push(e,o) =Y — o=V 
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(6.10) Yo € S. pop(o) = ¥ = o=¥ 


That is, if push and pop are applied to valid stacks, the result is guaranteed 
to be valid, and if they are applied to the invalid stack, the result stays 
invalid. 

With the help of v, I give the definition of cs in Definition 6.14. 


Definition 6.14. 
cs : Paths(G) > Sy 


is defined by 
cs(e) =€ 
cs(n ) ife € Eintra 
push(e, u ife € Eca 
cs(T e) = cs(n )= ife € Eret and cs(r) =e 
{ve} 
®D 


pop( s(n)) ife € Ere Acs(n) € 
A (top(es(n)),e) € 


hÁ otherwise 


If a path 7 can be fully traversed without resulting in the invalid stack, I 
call 7 S-acceptable?? 


Definition 6.15. The S-acceptable paths are given by 


APs(s,t) =, {n € Pathsc(s,t) | cs(r) + Y}. 


Next, I introduce Constraint System 6.5, which can be used to describe the 
data-flows along paths from AP. Like the previous constraint systems, its 
idea is to simulate what happens when we extend a path by one edge. In 
addition to the application of the corresponding edge function, Constraint 
System 6.5 also considers the effect of the edge on the stack - this is why 
the variables in Constraint System 6.5 have an additional stack component. 


Constraint System 6.5. Let S = (Eca, S, <, €, push, pop, top) be a stack space 
over Eca. Then Xs : NXN XS > Fa is a S-solution if it satisfies the following 


33A similar definition can be found in the work of Sharir and Pnueli[154, p. 227]. 
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constraints: 
í j í j ec Emm tot 
EMPTY s) ———————— INTRA s) — 
s Xs(s,s,€) 2 id 3 Xs(s,t,0) = feo Xs(s,t’,c) 
, call , 
fui j al EEan t >t oo = push(ecq, 0’) 
3 Xg(5,t,0) 2 feo Xt) 
+ Cret 
(eer) eret € Eret tot 
S “ Xg(s,t,€) > fer 0Xs5(s,t’,€) 
e 
(rer?) it (Call, Cret) € P pop(push (€cqy,o)) = 6 push(ecan, 0) # € 
S Xs(s,t,0) > fe ° Xs(s, t ,push(ecan, 0)) 


Like for previous constraint systems, I want to make some remarks on 
how to read and interpret Constraint System 6.5. 

First of all, the set of variables of Constraint System 6.5 is N x N x S. Hence, 
solutions to Constraint System 6.5 live in the complete lattice 


NxNxS—- Fr 


Moreover, I extend the function symbols and their interpretation function 
to also cover the stack operations. Analogously to previous constraint 
systems, for each occurrence of such a stack operation in a constraint in the 
lower part of one of the rules, I actually mean the corresponding function 
symbol. Regarding the upper part, I again want to remind the reader that 
the upper part of the rules specifies conditions under which the constraint 
in the lower part of the rule is contained in the set of constraints that makes 
up Constraint System 6.5. As an example, consider (6.5): It contains a 
constraint of the form 


Xs(s,t,0) = fey °Xs(s,t’,0") 
for alls,t,! € N, e..ı € E and 0,0’ € S such that e € Eg, t > tand 


o= push (call, or): 
Theorem 6.16 gives a correctness result for Constraint System 6.5. 
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Theorem 6.16. Let X : NX NxS — Fg bea S-solution. Then for arbitrary 
s,t € N we have 


(6.11) Yr € Pathsg(s,t). n € APs(s,t) => frn < X(s,t,cs(7)) 
In particular, X(s,t) = | Joes X(s, t,o) defines a MOAP s-correct solution. 


Proof. First assume that (6.11) is proven. Then 


Yr € APs(s,t). fn < X(s,t,cs(n )<| |X@,t,0) = X(s,t) 


o€S 


so that 


MOAPs(s,t)= || frsX(st 
m€AP 5 (s,t) 


Now we prove (6.11) by induction on the length of paths. Let n € N. The 
induction hypothesis is 


(IH) Yn € Pathsc(s,t).In|<nAneAPs(s,t) => fr < X(s,t,cs(7)) 
We show 

(6.12) Yr € Pathsc(s,t). In|=nAneAPs(s,t) => frn < X(s,t,cs(7)) 
by case distinction on n. 

n =Q: clear by constraint EMPTYS. 


n> 0: Letn be a path from s tot with |n| = n > 0and nz € APs(s,t). Hence, 


we can write n = n’ -e with n’ € Pathsc(s,t’) and t’ £t. Moreover, since 
n € APs(s,t), it must be n’ € APs(s,t) as well (this follows from the 
definition of cs). By definition, (IH), and (6.3), we see that 


fn < feo X(s,ť ,cs(T')). 
Then we show 
feo X(s,t’,cs(m’)) < X(s, t,cs(7)) 


by case distinction on e: 
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© e € Ejytra: Then cs(m) = cs(n’) and hence 
feo X(s,t’,cs(m’)) < X(s,t,cs(m’)) {constraint INTRAg } 


= X(s,t,cs(m)) {since cs(n’) = cs(n) } 


© e = Col € Ecg: Then cs(m) = push(e..,cs(r’)) and hence we can 
conclude 


fean ° X(8,t',c8(1’)) < X(s,t,cs(7))) 


by CALLs. 


e = ere € Eret: By definition of cs and since cs(n) + Y by assump- 
tion, it must be either cs(n) = cs(n’) = e or cs(n’) € {v,e} and 
(top(cs(r’),eret)) € ©. We consider each of these cases individually. 


1. If cs(m’) = cs(n) = e, we can make the following reasoning: 


Feret oX(s, t’,cs(m’)) = Seret Q X(s, t,e) { cs“ (N) =e } 
< X(s,t,€) { by RET? } 
= X(s,t,cs(7)) {ces(n) =e} 


d 
2. If cs(n’) ¢ {ve} and (fop(cs(m’),eret)) € ®, then for esal a 
top(cs(m’)) we have (eca eret) € ® and cs(n) = pop(cs(n’)) (by 
definition of cs), hence 


(6.13) es(m") = push(ecan,cs(r)) = push (ecan, pop(cs(T’))) 


(2) 


S and 


by (NEPushPop) and (TopPush). Hence, we can apply RET 
conclude: 


Seret 9 X(s, r, cs(r’)) 
T Seret 2 X(s, r, push(ecall, cs(rt))) { (6.13) } 
< X(s,t,cs(7)) { by RETZ) } 
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oO 


Theorem 6.16 states that MOAP s can be correctly approximated by com- 
puting a solution of Constraint System 6.5 and subsequently joining over 
all stacks. 

In order to give a precision result for Constraint System 6.5, I need a variant 
of MOAP that has an additional stack component. This variant is defined 


in Definition 6.17. MOCH 


APs (s, t, 0) only merges over those paths that leave 
behind stack o. 


Definition 6.17. The stack-based Merge-Over-All-S-Acceptable-Paths solution 
MOSM” : NXN XS mon Fa 
S 


is defined by 
Stack, 
MOPS (s, t,o) = | fr 

neVP(s,t),cso (n)=o 
Now I show that Constraint System 6.5 is also able to precisely describe 
MOAPs, provided that F is universally distributive. 
Theorem 6.18. Let F be a universally distributive framework. Then Moon) 
is an S-solution. In particular, for the least S-solution X, we have X < More . 


Proof. We show that Moe satisfies all the constraints of Constraint 
System 6.5. 


EMPTYg Lets € N. Then MO, s,€) = id. So, EMPTY is satisfied. 


INTRAS Let st! € N, e € Eye, t £ tando € S. Then for every 
tt’ € AP s(s,t’) with csoo(m’) = o we have n’ -e € AP s(s,t) and cs(m’-e) = 
cs(n’) = o. This implies 


(Stack) 
MO,» (s,t,0) 
=| tfc In € APs(s,t),cs(r) =o} { definition } 
> | Irre | rn’ € APs(s,t’),cs(n’) = o} { see above } 
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=| Veo fw Im’ € APs(s,t’),cs(n’) = o} { definition } 
= feo] U In’ € APs(s,t’),cs(n’) = o} { fe is u.d. } 
= foo MOP?) (5, 77,0) { definition } 


Ecall 


CALLS Let s,t,t EN, ea € Egy, X > tando € S. Then for ey. 
n’ € AP(s,t’) with cs(n’) = o we have n’ -eg € APs(s,t) with cs(n’ 
Ccall) = push(ecan,cs(r’)) = push (cai, 0). Hence 


moors (s, t, push (Ccallr o)) 
= | {fn |mneAPs(s,t),cso(r) = pu ne o)} {definition } 
> | [irren 17 € APs (s, t)r) = (see above] 
= | ecan 2 fw IT € APs(s,t’),cs(r’) { definition } 
= Secatt ° | Jr In’ € APs(s,t’),cs(r’) { fea is u-d. } 
= fec 2 Mo iack) (s,ť,0) { definition } 


ery) Let s,t,t’ EN, ere € Evert, t g t,o € Sand n’ € APs(s,!’) with 
cs(n’) = e. Then 7’ -eret € AP s(s,t) and cs(r’ - eret) = €. Hence, we may 
conclude 


Stack 
Moĝiac Ys, t,€) 
=| Jfr In € APs(s,t),cs(r) =e} { definition } 
> tee |z € AP s(s,t’),cs(m’) = e} { see above } 


=| Wea o far Im’ € APs(s,t"),cs(’) =e} {definition} 

= fer | [fw lm’ € APs(s,t’),cs(7’) =e} 1 ferg iS u.d. } 

Shr MO ANETA { definition } 
rer) Let o € S with push(e,gy,0) + € and pop(push(e,gy,0)) = o. Fur- 


e 
thermore, let s,t, te N, ecall E Egat eret © Eret, t = t, (€calt, eret) € ®, and 
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push(ecay,0). Then n’ -eret € AP s(s,t) and 


n’ € APs(s,t’) with cs(n’) = 
= pop(push(e..1,0)) = 0. This justifies that we 


cs(T - eret) = pop(cs(m’) 
conclude 


MOP" (s,1,0) 
=| Jfr Im € AP(s),cs{r) =o} { definition | 
> Bae | mr’ € AP(s,t’),cs(m’) = push(ecqy,0)} { see above } 
=| Wer © fm Im’ € AP(s,t’),cs(n’) = push(e.a,0)} {definition } 
= feret O | Jv In’ € AP(s,t’),cs(m’) = push(eca0)} 1 fere is ud. } 
= fey MOD (5,1, push(ecan 0)) { definition | 


6.3.2 The Unbounded Stack Space 


Up until now, we only have compared solutions to the abstract set APs. 
The subject of this and the following subsection is to examine stack spaces 
for which APs relates to VP in a meaningful way. From the results, I will 
derive VP-correctness and VP-precision results in subsection 6.3.4 

In this subsection, I consider the very important special case of the space 
Soo of unbounded stacks. My main result for this subsection is that the 
Soo-acceptable paths coincide with the valid paths. 

The proof is split up into two parts. In the first part, I show that every 
valid path is S.o-acceptable. After that, I show every S.o-acceptable path 
is valid. 


6.3.2.1 Valid Paths Are S,.-Acceptable 


Theorem 6.21 states that every valid path is S..-acceptable. It makes use 
of two elementary properties of cs» concerning same-level and ascending 
paths. 

The first property states that appending a same-level path does not change 
the stack. This is not surprising as same-level paths are balanced and valid, 
which means that for every call there is a return and that every return 
corresponds to the innermost call. 
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Lemma 6.19. If 7’ is a same-level path, then 
Yr € Paths(G).cso (T: T) = cS% (T) 
Proof. Induction on n’ € SL with arbitrary 7. Oo 


The second property, which is stated in Lemma 6.20, considers ascending 
paths. Basically, an ascending path is like a same-level path with an excess 
of return edges. Hence, if we start with an empty stack and have traversed 
the same-level prefix, the stack is empty. Then traversing the rest of the 
path leaves the stack empty. Note that this property also highlights a 
specific characteristic of my treatment of stacks. Because I not only consider 
descending paths, I have to handle the case of returning from an empty 
stack, which is not a valid situation in a normal program. In my definition 
of cs», I allow returning to any call site if the stack is empty, as long as 
stack usage is acceptable in the case that the stack is not empty. 


Lemma 6.20. If 7 is an ascending path, then csoo(T) = e€. 
Proof. By induction on rn € ASC. 
e The claim is clear for n = e. 


e Suppose that the claim holds for n’ € ASC(s,t’) and we have n = 
nm’ -e with e € Entra U Eret and > t. Then we distinguish two cases: 


— Ife € Eintr, it follows that 


CST + €) = cso(T) { by definition } 
=€ { by induction hypothesis } 


- Ife € Ere, we know csœ(T' ) = e by induction hypothesis and 
can thus follow cs» (rt) = e by definition of cs. 


call 


e Suppose that the claim holds for n’ € ASC(s,n), we have n > 
no, n” € SL(no, n1), nı = tand (Ecall,Erer) € ®. Then we have 


CSoo (T + ecall T” + eret) = CS (T) {by Lemma 6.19 } 


=€ { by induction hypothesis } 
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oO 


With help of Lemma 6.19 and Lemma 6.20, I can prove acceptability of 
valid paths. 


Theorem 6.21. If n € VP(s, t), then cso (T) # Vo. 


Proof. We use Theorem 5.30. Let nı € ASC(s,t’) be an ascending path 
starting with s and ending in some arbitrary t’ € N, then it suffices to prove 


Yr € DESC. Yt € N. m € DESC(#’, t) — C800 (71 + 12) # Vo. 
We prove this statement by induction on 72 € DESC. 


e If m2 = e, then nı nn € ASC(s,t). Hence, cs» (TI T2) = e by 
Lemma 6.20. 


e Otherwise, we are in case DESC-SEQgesc OF DESC-SEQ,; and have m2 = 


ny: ny for some n, € DESC and either n% € E.. or ny € SL. 


In either case, we can apply the respective induction hypothesis and 
get 


(IH) CSo (711 + 15) # Yoo. 


We consider these two cases separately. 


e 
— Let ny = ecan € Ecan, with t” = Then, we can conclude 


CSoo (TC + 712 * Exall) 


= pusho (Ecall, CS (71 © T2)) { definition } 
EV { (IH), (6.9) } 
- ltm=n,:n, with n, € DESC(#’, t”) and my € SL(#’’, t) for 


some t” € N. Then, we can conclude 


CS00(714 T . Tt ) = CS (Tq $ T4) { 104 € SL, Lemma 6.19 } 
# Yo. { (TH) } 
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6.3.2.2 S..-Acceptable Paths Are Valid 


For the property that cs» only accepts valid paths, which I will show and 
prove in Lemma 6.24, I need two additional properties of cs» that are also 
of interest on their own. 

The first property formally describes the possible shapes of a path x 
for which cs (rt) is not empty: Suppose that csoo(7™) = egqyy +o. Then 
intuitively, it can only be the case that (a) some prefix of r left behind stack 
a, (b) then eq] was encountered and (c) the part after e,,7 is a same-level 
path that leaves the stack unchanged. Lemma 6.22 states that this is indeed 
the case. 


Lemma 6.22. If r € Pathsg(s,t) and cs% (T) = ecaj ` o, then t can be split up 
into n = T’ + Ccqy Tt’ Where cso (T) = o and T” is a same-level path. 


Proof. We fix s € N and prove the result for all n € Pathsg(s,t) with 
arbitrary t € N, e € Eg and o € Eri by induction on the length of 
paths. Let n € N and assume that the claim is true for all nz’ with 
In’| < n. Let no € Pathsg(s, t), ecan € Eca, 0 € EX, such that [ro] = n and 
CSoo (No) = call ` O- 

First we observe that n > 0, since cso(e) = €. So Tto = T : e for some e € E. 
We make a case distinction on e: 


e € Ejntra: Then csoo(™@-e) = CSoo(™). Hence, we can apply the induc- 
tion hypothesis on 7 and get a decomposition n = n’ -ecaj + T” where 
CSœ (T) = o and 7” is a same-level path. Hence n -e = n’ :e..ı: (T +e) is 
a decomposition of 7 - e with the desired properties: 7” -e is a same-level 
path, since e € Ejntra- 


e € Eag: Then csoo(M +e) = €+CSco(M) = eca’ CSoo(T), SO e = ec and 
o = CSœ (T1) # Yoo. Now we make a case distinction on whether cs» (Tr) is 
empty or not. 


e If cs» (rt) is not empty, then cs» (rt) = e’- 0’ for some e’ € Eq and 
o’ € E* .. We apply the induction hypothesis on 7 and obtain n’ with 
call 
CSœ (T) = 0’ and a same-level path n’ such that 


an net” 
Then 


(6.14) n-e =n e n” -e=(n’-e-m")-e-€ 
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€ is a same-level path, so in order to show that 6.14 is a decomposition 
of n - e with the desired properties, we only need to show CSc0(71’ : €’ - 


T”) = cso(n) = e’ - 0’. But this can be seen as follows: 


CS (T e. n”) = C800 (T -¢’) { n" € SL, Lemma 6.19 } 
=e'.cs»(n’) {by definition of cso, e € Eggi } 


=. (sol) = 07 } 


e If cSoo(m) = e, then o = € = csœ(T) so that n-e = n-e-eisa 
decomposition with the desired properties. 


e € Ere: We have eca ‘0 = CS (T: e) = popo (C800 (71) ), So that by definition 
CST) = e - (eca +o) for some e’ € Esa with (e’,e) € ®. We apply the 
induction hypothesis on r (|n| < n) and get n’, n” such that cs» (r’) = 
ecall © 0, T” is a same-level path and 


m= -e-n 


, 


Next we apply the induction hypothesis on 7’ (In’| < n) and get 71), 7, 


such that cS% (73) =o, Ty is a same-level path and 


$ / / 
T = T ` ecall * Thy 
That means 7 - e can be decomposed into 
(6.15) TL = Tey Era Th E Tl + € = Ty + Cray: (73e ne) 


Since (e’,e) € ® and n” is a same-level path, e’- n” -e is a same-level 
path. Since 7) is also a same-level path, nr, - e” - n” -e is a same-level path. 
Furthermore, cS0o(7,) = o. In summary, 6.15 is a decomposition of 7 - e 
with the desired properties. 


oO 


The second property that will be needed in my proof of Lemma 6.24 is the 
converse of Lemma 6.20: Empty stacks can only be left behind by ascending 
paths. In particular, even though cs» allows returning to arbitrary call sites 
in the face of the empty stack, apart from this exception, it still requires 
that paths exhibit valid stack usage. 
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Lemma 6.23. If n € Pathsg(s,t) with cso(Tt) = €%, then n € ASC(s,t). 


Proof. I prove the result by induction on the length of paths. 
The induction hypothesis is 


(IH)  Vre Pathso. Ys,t € N. |n| < n A n € Pathsg(s,t) Acso(n) = € 
== nE ASC(s,t) 


Let n € Pathsg with |n| = n and s,t € N such that n € Pathsg(s,t). 
Furthermore, assume cs» (rt) = €. We need to show n € ASC(s,t). For 
this, we distinguish two cases: 


n = 0: Then 7 must be empty and is hence ascending, so that the claim 
holds in this case. 


n> 0: Then m = n’ -eand rn’ € Pathsc(s,t’) for some t’ € N,e € E, t’ SH 
Since cs» (rt) = e, it cannot be the case that e € E.„ı, so we only need to 
distinguish the cases e € Ejytr. and e € Eyer: 


e € Ejntra: Then cs&(n) = csw(n’), so that cso(r’) = e. Hence we may 
apply (IH) to 7’ and conclude n’ € ASC(s,t’). Thus n = n’ -e € ASC(s, t) 
by asc-asc. 

e € Eye: By definition, cs» (rt) = e implies that either cs» (n’) = e or that 
So (N) = Eoall for some Ccall E Ecall with (Ecall, e) eo. 

In the former case, we may reason just as for the case “e € Eintra”: Applying 
(IH), we obtain n’ € ASC(s, t’) and appending a return edge to an ascending 
path results in an ascending path. 


In the latter case, we apply Lemma 6.22 and decompose 7’ into n’ = n” - 
ecall : T” such that csœ (r”’) = e and n” is a same-level path. Then we 
apply (IH) to 7” and conclude that 7” is an ascending path. Furthermore, 
since (e..1,e) € ® and n” is same-level, n = T” - e.g + T” -e is ascending 
by asc-sEQ,;. With n € Pathsc(s,t), we get n € ASC(s,t) by definition. 


Lemma 6.24. If n € Pathsg(s,t) with cso(Tt) # Yoo, then n is a valid path. 
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Proof. If cso(Tt) # Yoo, then cso(n) € E* ,, so we prove the claim by 
induction on the length of cs» (n). So let n € N. 
The induction hypothesis is 


(TH) Yr € Pathsg. |cSoo(1)| <nAcso(N) + Yo => TE VP 


Let 7 € Pathsg(s,t) with cs& (N) # Yoo, |CSoo(7)| = n. We distinguish two 
cases: 


n =0: Then csoo(7) = e. By Lemma 6.23, n € ASC c VP. 


n>0: Then csoo(7) = e:o for some e € Ey. By Lemma 6.22, n can be 
decomposed into n = n’ -e- n” where cs&(r’) = o and 7” is a same-level 
path. In particular, cs» (rn’) # Yœ and |cs»(r’)| < n, so we may apply 
(IH) and get that n’ € VP. Furthermore, since e € E..ı; and n” and is 
same-level, e- rı’’ is descending by Theorem 5.29. Furthermore, e- m” is a 
path because it is a sub-sequence of 7 and r isa path. Hence, e- n” € DESC 
by Theorem 5.37. 


Thus, 7 is the concatenation of a valid sequence and a descending sequence 
and therefore valid by Theorem 5.30. With r € Pathsg, we get n € VP by 
definition. 


6.3.2.3 Summary 


After I have proven the two subset relations, I formally state the main 
result of this subsection, namely that APs, coincides with VP, for later 
reference. 


Theorem 6.25. The valid paths are exactly the S-acceptable paths for S = Soo: 
APs. = VP 
Proof. “C” is shown by Lemma 6.24 and “2” by Theorem 6.21. m| 


As a corollary, I conclude that for distributive frameworks, the least 
solution Constraint System 6.5 w.r.t. Soo coincides with MOVP and hence 
provides the same result as the functional approach. Thus, I can confirm 
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the corresponding result, that Sharir and Pnueli [154, Theorem 7-4.6] 
showed for classical data-flow analyses on interprocedural graphs in my 
more general setting. 


6.3.3 Stack Abstractions 


In the last subsections, we have seen that Constraint System 6.5 correctly 
and precisely describes the data-flows along the valid paths in the case 
that Constraint System 6.5 is based on the stack space Soo of unbounded 
stacks. In this sense, the unbounded call-string approach coincides with the 
functional approach. 

In this and the next subsection, I examine general stack spaces. Specific- 
ally, I present an approach for providing correctness results for general 
stack spaces. Therefore, this subsection introduces the concept of stack 
abstractions. A stack abstraction is a function between stack spaces that 
preserves enough structure to maintain acceptability of paths. My main 
result is that if a stack space S is related to a stack space S* via a stack 
abstraction, then all S-acceptable paths are S*-acceptable. This enables to 
conclude VP-correctness of MOAP + from VP-correctness of MOAPs. 

In subsection 6.3.4, I will apply this result to obtain a VP-correctness result 
for MOAPs,. 

Stack abstractions make use of galois connections, a concept that is well- 
known in mathematics and also static program analysis. 

A galois connection can be seen as a generalization of inverse functions 
for partial orders. Definition 6.26 can be found e.g. in [130, Section 4.3] or 
[50, 7.23, p. 155]. 


Definition 6.26. Let (L, <) and (M, <m) be two partially ordered sets and 


a:L7M 
y:M>L 


be two monotone functions. Then (L, a, y, M) is called a galois connection if 
aoy <m idy and id, <p yoa. 


Lemma 6.27 gives a simple characterization of galois connections, that I 
will make use of occasionally in the following. 
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Lemma 6.27. (L,M,a,y) is a galois connection between the partially ordered 
sets (L, <) and (M, <m) if and only fa: L— Mandy : M > Mare monotone 
functions such that 


Wie L.VmeM.a(l) smm = l<; y(m) 


Proof. See [130, Proposition 4.20]. Note that [130] actually assumes that 
Land M are complete lattices, which is not necessary for the proof to be 
valid. Oo 


Next, Definition 6.28 introduces stack abstractions, the main concept of 
this subsection. 


Definition 6.28. A stack abstraction between two stack spaces 
(S, <, €, top, push, pop) 


and 
(SË, <", e", top", push", pop*) 


is a pair (a, y) of functions 


a:Sy > Sta 


y Sty > Sy 
such that 
(Gal) (Sw,a,Yy, Sa) is a galois connection. 
(Bot) y(v*) =Y 
(Eps) Vof e SË. y(o#) =e => ot = ef 
(PushHom) Vo" € S*. a(push(e,y(o*))) <* push*(e,o*) 
(PopHom) Vo" € S*— {ef}. a(pop(y(o*))) <* pop*(o*) 
(TopHom) Vo" € S* - {e*}. top(o*) = top(y(o*)) 


Before I show an example of Definition 6.28, I want to discuss a bit the 
intuition behind stack abstraction and their en 

For this, consider a stack abstraction (S,a,y,S*) between two stack spaces 
S = (S, <,e, top, push, pop) and S* = (S, <, e, top, push, pop). 
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A stack abstraction is supposed to “abstract away” from unnecessary 
details in a stack space while still preserving enough structure to make 
meaningful statements. For example, it shall enable to conclude from the 
validness of cs(rı), that cs" (rt) is also valid, i.e. it shall be possible to prove 
cs(n) +Y = cË (n) +Y. 

First of all, (Gal) provides a formalization of the intuitive notion of abstrac- 
tion. The function a, which is in the program analysis context also called 
abstraction function, can be thought of “abstracting away the details” from 
a concrete stack from S, whereas y, also called concretization function, maps 
an abstract stack to a corresponding concrete stack. 

Intuitively, we expect two properties of abstractions and their concretiza- 
tions. For one, if we abstract a stack and then concretize again, then we 
get a concrete stack that provides at most as much as the original stack. In 
particular, this stack should be comparable to the original stack. Secondly, 
if we concretize an abstract stack and then abstract it, then we get a stack 
that provides at least as much information as the original abstract stack. 
This is exactly what is achieved by the galois connection provided by (Gal). 
For every ø € S, there is a corresponding stack a(c) € S*, which can be 
thought of as “at most as detailed” as o. This is to be understood in the 
following sense: If we apply y to a(o), we arrive at a stack y(a(o)) with 
o < yla(o)). 

Conversely, for every stack o* € S*, there is a corresponding stack y (0#) € S 
in S, which can be though of as “at least as detailed”. This is to be 
understood in the following sense: If we apply a to y(o*), we arrive at a 
stack a(y(o*)) < o". 

Next, I consider the other properties. (Gal) in connection with (Bot) and 
(Eps) is strong enough to fully preserve € and Y, as Remark 6.29 shows. 


Remark 6.29. For every stack abstraction, we have 


(6.16) a(e) =e 
(6.17) yl) =e 
(6.18) a(x) = YË" => x= 


Proof. First, we consider (6.16) and (6.17). By (Gal), we have e < y(a(e)). 
Since e is the greatest element of S with respect to <, this means that 
y(a(e)) = e. Hence, a(e) = e* by (Eps). Again by application of (Gal), we 
have e < y(a(e)) = y(e*), so y(e*) = e by <-maximality of e. 
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Finally, we prove (6.18). For all o* € S* we have v < y(o*) since Y is the 
least element of Sy. By (Gal) and Lemma 6.27, this means that a(v) < o” 
for all o* € S*, which implies a(¥) = vi. Conversely, for o € Sy with 
a(o) = W* by (Gal) and (Bot) we have o < y(a(c)) = y(¥*) = Y, which 
implies o = V. Oo 


The other properties in Definition 6.28 ensure that a and y are well-behaved 
with respect to the stack operations. Property (TopHom) ensures that the 
top elements of a stack and its abstract versions are the same. The other 
two properties consider two different ways to perform a push or pop 
operation on abstract stacks: The first way applies the respective abstract 
operation, whereas the second way first concretizes the stack, applies 
the concrete operation and then abstracts the result. The two properties 
(PushHom) and (PopHom) state that the first way must provide as most 
as much information as the second way. 

In the following, I give an important example of a family of stack abstrac- 
tions. To support the uniform presentation of the following example, I 


d d 
define AS®  A* for an alphabet A, o5% D5 for every o € A* and 


def 


co—1 = œ. Furthermore, I assume that the natural order < on N is 
d 

extended to Noo 2 IN U {co} by defining x < œ for every x € No. 

Example 6.30. For k,l € Noo, | < k, consider the two stack spaces Sp = 


(E=, <k, Er, pushy, popp, topp) and S; = (ES <q, €1, pushy, pop;, top,). Define 
the dinctions ar and ygi by 


apila) = 0“ 
an (VK) =Y; 

Yrı(o) = 0 
YEW) = Vk 


Then (Sx, akı Yk Sı) is a stack abstraction. 
Proof. (Gal) (Sk ax, Yk Sı) is a galois connection. 


e Fora € ESK we have 
call 


o Sk oe { osl isa prefix of o } 
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{ definition of yx; } 
= yrıları(c)) { definition of ax } 


e Foro € E<! we have 
call 


a1 (7k 1(0)) = arı(o) KANN ee 
er; { definition of Akl } 
7 <l 
= [since ø € EZ, } 
= { Reflexivity of <; } 


(Bot) clear by definition. 
(Eps) This is clear since yx; is the identity function. 


(PushHom) Leto € ES Then we have 


ag (pushy (e, Yei(o))) = Ae (pushg(e,o)) {definition of yz; } 
= ayy ((e-)<*) { definition of push, } 
= ((e- o) 5S { definition of ax; } 
= (e-o)! {l<k} 
= pushy(e,o) { definition of push, } 


(PopHom) The claim is trivial for ] = 0, so we may assume ! > 0. For 
e-o€ ES \ {e}, we have 


a (pope (vr,(e:0))) = ax,ı(popk(e 0)) definition of yz; } 


{ 
= ax) (c)) { definition of pop, } 
=o! { definition of ax } 
= <I-1 <l 
=o: {oe Exam c Egl } 
= popı(e:o) { definition of pop; } 


(IopHom) Again, the claim is trivial for ! = 0, so we only consider l > 0. 
For e-o € ES \ {e}, we have yx ;(o) = o and therefore topk(yrı(o)) = 
top;(o). 
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After I have introduced stack abstractions and gave an example, I provide 
the main result of this subsection in Theorem 6.31. If S and S* are two 
stack spaces and a and y forma stack abstraction between S and S*, then 
every S-acceptable path is also S*-acceptable. 

The proof of Theorem 6.31 is an easy consequence of the following key 
property, which I will prove later. 


Lemma 6.32. Let (S,a,y,S*) be a stack abstraction between the stack spaces 
(S,<,€, top, push, pop) and (S*, <* et, top*, push”, pop”) over Eca. Then the 
following statement is true for any n € Paths(G): 

(6.21) a(cs(r)) < cs*(r) 

Lemma 6.32 can be used to show the main result of this section. 


Theorem 6.31. Let 
S = (Ea S, <, €, top, push, pop) 


and 

S* = (Ecan, S*, <*, €", top*, push“, pop*) 
be two stack spaces over Eq. Furthermore, let (S,a,y,S*) be a stack abstraction 
between S and S*. Then 
(6.19) Ys,t € N. APs(s,t) C AP s#(s,t) 
(6.20) MOAPs < MOAP + 
Proof. First, we show (6.19). Let n € APs(s,t). Then cs(7) + ¥ which 
by Remark 6.29 implies a(cs(rt)) + Y#. By Lemma 6.32 it follows that 
a(cs(r)) < cs* (7), which entails cs*(rt) + Y”. Thus n € AP s#(s,t). 


With (6.19), we see that MOAP <y joins over more paths than MOAP s. This 
shows (6.20). m 


All that is left to do for this subsection is to prove Lemma 6.32. 


Lemma 6.32. Let (S,a,y,S*) be a stack abstraction between the stack spaces 
(S, <,e, top, push, pop) and (S*, <*, e", top*, push*, pop*) over Ecqy. Then the 
following statement is true for any n € Paths(G): 
(6.21) a(cs(n)) < cs* (r) 
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Proof. First, we observe that 
(6.22) a(cs(1)) < c# (n) <= cs(n) < y(cs*(m)) 


This follows from (Gal) and Lemma 6.27. 
Next we show 
Wn € Paths(G). a(cs(n)) < cs*(r) 


by induction on the length of 7. So let n € IN, n € Paths(G) with |n| = n. 
The induction hypothesis is 

(IH) Vn’ € Paths(G).|n’|<n => a(cs(m)) < cs*(n) 

By (6.22), this is equivalent to 

(IH’) Yr’ € Paths(G).|n'|<n = cs(n’) < y(cs*(n’)) 

Now we make a case distinction on n. 


n = 0: Then n = e. Evaluation of both sides yields that they are equal: 
a(cs(r)) = a(e) = e* and cs*(n) = e*. 
n>0: Then m = 7’ -e with |n| =n- 1 and e € Eintra U Eca U Eret- 


First we consider the case that cs(n’) = v. Then cs(n) = Y and hence, by 
(6.18), a(cs(r)) = Y# < cs# (r). 


Next assume cs#(n’) = v*. Then (IH) implies a(cs(n’)) < v*. Hence, 
a(cs(r’)) = v*, and this implies cs(7’) = v by (6.18). As in the previous 
case, we can conclude that a(cs(7)) < cs*(7) also holds in this case. 


Now we can assume cs(n’) + Y and cs*(n’) + v* and make a case 
distinction on e: 


e € Eintr: 
n')) { by definition, e € Ejntra } 


{ (TH) } 


{ by definition, e € Eina } 
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ee Bas: 


a(es(r)) 

= a(push(e,cs(r’))) { by definition, e € Eggi } 
< a(push(e, y(cs*(r’))) { IHN), mon. of push(e,-) and a} 
< push* (e,cs*(n)) { 
{ 


= cs* (n) 


(PushHom) } 
by definition, e € E.aıı } 


case e € Eye: By definition of cs, we distinguish two cases: 


cs(n’)=e: By (IH’), this implies e < y(cs"(n’)). t follows that 


y(cs*(m’)) = e. Hence cs*(n’) = e* and, by definition of cs*, cs*(n) = e*. 


case cs(n’) + e By assumption, we have cs(n’) € {¥, e}. 


First consider the case that (top(cs(n’)),e) ¢ ®. Then cs(n) = Y by 
definition of cs. Hence, we can justify (6.21) as follows: 


alcs(n)) = a(¥) { see above } 
=y" { (6.18) } 
<cs*(n). {cs (n) € S*, W* is the least element of S* } 


Now we may assume that cs(n’) ¢ {v,e} A (top(cs(n’)),e) € ®. Consider 
the case that cs*(m’) = e*. Then cs*(r) = e*, so that a(cs(7)) < cs*(r) 
holds. 

Now assume cs* (r’) + e". Together with cs*(n’) + W*, me have (m) ¢ 
{v*, e*}. By (IH’), we have cs(n’) < y(cs*(n’)). Since cs*(n’) + e*, it must 
be y(cs*(r’)) + e (by (Eps)). 

Because cs*(m’) + e*,cs(n’) + € and y(cs*(n’)) + e, we can conclude from 
cs(r’) < y(cs*(r’)) that 


top(es(r’)) = top(y(cs*(n’))) = top (cs*(’)) 
by (TopVsLe) and (TopHom)). Together with (top(cs(7)),e) € ®, it follows 


that (top(cs*(7)),e) € ®, so that cs" (rt) = pop*(cs"(r’)) by definition of 
cs". Now we can conclude 
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= a(pop(cs(m’))) { definition of cs, assumptions } 
< a(pop(y(cs*(n’)))) { AH’), mon. of pop and a } 

< pop” (cs*(r’)) { (PopHom) } 

= cs*(r) { definition of cs*, see above } 


6.3.4 Effective and Correct Approximations of the 
Unbounded Call-String Approach 


In subsection 6.3.2, we saw that solutions of Constraint System 6.5 w.r.t. 
Soo enjoy the same correctness and precision results as the functional 
approaches. Unfortunately, Constraint System 6.5 is not effective. For one, 
Constraint System 6.5 w.r.t. Soo is infinite. Secondly, the complete lattice 
that forms the solution space of Constraint System 6.5 is 


NXNxS® > Fg, 


which does not satisfy the ascending chain condition. Particularly this 
second fact makes it impossible to use algorithms such as Algorithm 8, 
which rely on the ascending chain condition for termination. 

However, in Example 6.13 I showed the family of (Sx) en of stack spaces 
that lead to finite versions of Constraint System 6.5 and to solution spaces 
that satisfy the ascending chain condition. Hence algorithms like Algo- 
rithm 8 are applicable to Constraint System 6.5 w.r.t. Sp. The idea of Sy, 
which is at least since the work of Sharir and Pnueli [154] well-known in 
the literature, is to only consider the k topmost stack elements, so that all 
stacks are k-bounded. As Example 6.30 showed, Soo and Sx are connected 
via a stack abstraction, where the abstraction function projects a stack to 
the k topmost items. 

Consequently, the main result Theorem 6.31 from the last subsection 
enables me to transfer the correctness result for Soo to Sx. 
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Corollary 6.33. 1. Let S be a stack space such that there is a stack abstraction 
between Soo and S. Then the following statements hold: 


(6.23) Vs,t € N. VP(s,t) C APs(s,t) 
(6.24) Vs, t,€ N. MOVP(s,t) < MOAP(s, t) 


2. Let k,l € IN U {co} with | < k. Then the following statements hold: 


(6.25) MOVP < MOAPs, 
(6.26) MOAPs, < MOAPs, 


Proof. 1. (6.23) follows from Theorem 6.31 and Theorem 6.25. The second 
statement (6.24) is an easy consequence of (6.23). 


2. In Example 6.30 we have seen that (Sx, ax], x1, S1) is a stack abstraction 
if k,l € IN U {co} with! < k. This means that we can apply (6.23) and (6.24) 
to obtain the desired statements. 

oO 


Together with Theorem 7.34, this entails that solutions of Constraint 
System 6.5 w.r.t. Sy are VP-correct. Hence, using k-bounded stacks in 
the call-strings approach is indeed correct. This is a generalization of the 
corresponding result that was obtained by Sharir and Pnueli for classical 
data-flow analyses on interprocedural control-flow graph [154, Theorem 7- 
6.5]. For one, my assumptions about the given graph and its valid paths are 
weaker (as I already explained in chapter 5). Moreover, there may be other 
stack spaces than S; that can be obtained from S% via a stack abstraction 
and lead to an effective version of Constraint System 6.5. The theory that I 
developed in this section provides a way to prove VP-correctness for all 
these stack spaces. 
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GEORGE HARRISON 


A Common Generalization of 
Interprocedural 
Data-Flow Analysis and Slicing 


After chapter 6 introduced constraint systems for the functional and the call- 
string approach to interprocedural data-flow analysis for interprocedural 
graphs, this chapter is concerned with the effective solution of meaningful 
portions of these constraint systems in order to compute correct and 
possibly precise approximations to MOVP. 

In chapter 3, I compared slicers such as Algorithm 5 and Algorithm 6 
with algorithms to solve data-flow problems, such as Algorithm 3. My 
conclusion was that although both algorithm groups are worklist-based, 
they differ in what I coined as worklist policy. While the slicers usually 
assume that worklist items just have been updated, update the values of 
their successors and put them on the worklist if their value has changed, 
Algorithm 3 acts on the assumption that worklist items have to be updated, 
updates them using all their predecessors and then puts all successors on 
the worklist. This difference becomes obvious if one considers how the two 
approaches handle reachability. While slicers are reachability analyses and 
naturally explore graphs iteratively using a reachability frontier, Algori- 
thm 3 is geared towards situations where the goal is to compute values for 
every variable and the usual assumption is that every variable is reachable. 
Hence, Algorithm 3 proceeds rather clumsily if the analysis information 
to be computed is reachability itself: It uses the rule “this variable is 
reachable if one of its predecessors is reachable” and not - like it is natural 
— “if this variable is reachable, then all its successors are reachable”. It 
is possible to use Algorithm 3 for data-flow problems where reachability 
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is part of the analysis result, even without modifications. However, this 
necessitates modifications of the data-flow problems. Moreover, the initial 
loop, which iterates through all variables cannot be eliminated - its task is 
to assess that all unreachable variables are indeed unreachable because all 
their predecessors are. I take a different path to integrate reachability and 
data-flow analysis and modify Algorithm 3 in such a way that it is geared 
towards reachability and computes the actual analysis result for reachable 
variables as a side-product. Particularly, Algorithm 8, my modified version 
of Algorithm 3, does not need to visit every variable at least once but only 
the reachable variables. 

The presentation and analysis of Algorithm 8 will be the subject of sec- 
tion 7.1. 

Moreover, section 7.1 considers reachability and partial solution on the 
level of constraint systems. This is particularly necessary to be able to make 
statements about the properties of Algorithm 8. Moreover, I investigate 
under which circumstances the least solution of the restricted constraint 
system coincides with the least solution of the full constraint system on 
the reachable variables. This can also be seen as slicing of constraint systems. 
It turns out that the modified version of Algorithm 3 is indeed capable of 
computing such partial solutions. 

Subsequently, I apply the theory developed in section 7.1 to the constraint 
systems given in chapter 6 in order to obtain algorithms that compute 
correct data-flow solutions on forward slices. Section 7.2 lays out the 
setup and gives an overview of the general scheme. Then, section 7.3 and 
section 7.4 consider the functional approach and the call-string approach, 
respectively. 


7.1 Integrating Reachability Into the Solution 
Process 


As was already mentioned at the very beginning of this chapter, the goal 
of this section is to present Algorithm 8, a variant of Algorithm 3 that 
additionally takes a set X of initial variables and solves only the part of 
the given constraint system that is reachable from this initial set of variables. 
This set cannot be chosen arbitrarily: The properties that Xo has to satisfy 
in order for Algorithm 8 are one of the topics of this section. How Xo is 
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chosen concretely is dependent on the context and will be discussed in 
later sections of this chapter. 

In the following, I consider a complete lattice L that satisfies the ascending 
chain condition. The idea behind Algorithm 8 is that it starts with applying 
the defining constraints of Xp and then proceeds by applying all constraints 
that use variables from Xp. Then it considers the variables whose values 
have changed in the same way and continues this procedure until no more 
value is changed. In the end, Algorithm 8 has computed a partial solution 
of the given constraint system and explored the variables and constraints 
that are reachable from Xo using a chain of def-use relations. 

To make this idea work, I need a way to distinguish variables that have 
been explored and whose solution value may be Lz from those which have 
not yet been explored and never will be**. For this purpose, I introduce a 
fresh value & that represents undefinedness and extend L to La. Moreover, 
I also extend the interpretation so that it can also take & as input and 
assume that the extended interpretation has the properties (7.1) and (7.2). 
Remember from chapter 2 that FV (t) denotes the set of variables occurring 
int. 


(7.1) Veel.m<sx 
(7.2) Wx>teC. Vp: X > Lg. [t] (y) = x% 
=> Av’ c€ FV (t). y(x) =R. 


These two properties ensure that reachable variables which are set to the 
ordinary L element of L can be distinguished from those variables which 
have not been reached yet or will never be reached. Particularly, the second 
property ensures that reachability is maintained. 

Also, the extension of L to Lg is always possible without destroying 
important properties of L. La is still complete lattice that satisfies the 
ascending chain condition. 

Note that in general (7.2) restricts the possible interpretations, since (7.2) 
essentially enforces that a constraint can be omitted if not all variables on 
its right-hand side have defining constraints. 


34Note that the unreachable variables do not actually exist in the memory of a machine 
executing Algorithm 8. In practice, the reachability of a variable can be assessed by evaluating 
whether Algorithm 8 already has assigned a value to this variable. Nevertheless, I need this 
additional element & to reason theoretically about unreachable variables. 
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However, the semantics functional [-] : Expr (F a X) — Fa that corres- 


ponds to a data-flow framework instance F = (G,L,F,p) and that I 
specified in section 6.1 satisfies both (7.1) and (7.2): (7.1) follows from 
(5.12) and (5.13), while (7.2) can be shown by induction with the help of 
(5.16) and (5.15). 

Next, I want to give a formal definition of reachable constraints and 
variables. For motivation, I give an example. Consider the constraint 
system C that consists of the constraints 


c1 : 01 2 f(v2,03) 
C2 : U2 2 g(v3) 

C3 : V3 2A 

C4 : v4 > h(v3, 05) 
c5:v4 2b 


where f,g,h,a,b are function symbols with appropriate interpretations 
and the v; are variables. 

If we start with v3 and follow the def-use chains in C, we see that cy, C2, cz 
and c4 are the constraints from C that are reachable from v3. Moreover, the 
reachable variables are v1, v2 and v3. 

Also note that cq is not really useful as it uses the variable v5, which does 
not have any defining constraints in C. Hence, no solution of C needs to 
assign vs any defined value. Particularly, the least solution /fp(Fc) must 
map v4 to &, which implies that I fp(Fe) (va) = Ifp(Fe\c,}) (v4). Similarly, 
we can conclude that it is not really useful to start with variables that 
have defining constraints with non-constant right-hand side, if one wants 
to preserve the least solution for the reachable variables. For example, 
if we start with v2, then we get the reachable constraints cı and c2, but 
both use v3, which is defined by neither cı nor ca, so that Ifp(Fe)(v;) and 
lfp(Fc) (02) both become BR if we restrict C to {c1, c2}. 

Given a variable set Xọ < X, the following definition introduces the 
sets Core(C, Xo) and CoreVars(C, Xo). The former captures the set of 
constraints that are obtained by starting at Xp and following the def- 
use chains in C, while the latter characterizes the variables defined by 
constraints from Core(C, Xo). 
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Remember from chapter 2 that Vars(C) is the set of variables that occur 
on the left-hand sides of constraints in C and that Def (x) is the set of 
constraints for which x occurs on the left-hand side, respectively. 


Definition 7.1 (core and core variables of a constraint system). Let C be a 
constraint system and Xo < X be a set of variables. 


1. Core(C, Xo), the core of C with respect to Xo, is defined as the least subset 
Co S C with the following closure properties: 


(C-Basz) Yx>t € C. FV(t) = 0 Ax € Xo => x2telCy 
(C-STEP) Vx>teC.FV(t) #0 
AVx! € FV (t). Def (x) NACo #0 — x2teCy 


2. CoreVars(C, Xo), the core variables of C, is defined as the least subset 
X. © Vars(C) that has the following closure properties: 


(V-Base) Yx>t€C.FV(t) =OAx€ Xo —xeX, 
(V-STEP) Yx>t € C. FV(t) #OAFV(t) € Xe => xE Xe 


The following two lemmas shed some light on the properties of Core and 
CoreVars and will be of great use later. 


Lemma 7.2. 
Vars(Core(C, Xo)) = CoreVars(C, Xo) 


Proof. 2: Show that Vars(Core(C, X9)) has the closure properties of 
CoreVars(C, Xo): 


1. Let x>t € C with FV (t) = @ and x € Xo. Then x>t € Core(C, Xo), i.e. 
x € Vars(Core(C, Xo)). 


2. Let x>t € C with FV(t) + Ø and FV(t) < Vars(Core(C,Xo)). Then for 
every x’ € FV(t), Def(x’) NCore(C, Xo) + 0. Hence, x>t € Core(C, Xo), 
which means that x € Vars(Core(C, Xq)). 


C: Define 


def 


Co = {x=t €C |x € CoreVars(C, Xq)} 
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Then 
(x) Vars(Co) = CoreVars(C, Xo). 
This can be seen as follows: 


e If x € Vars(Co), then there is x>t € Cg. By definition, this means that 
x € CoreVars(C, Xo). 


e If x € CoreVars(C, Xo), then it can easily be seen that Def (x) + 0. 
However, since x € CoreVars(C, Xo), it follows that De f(x) < Co, so 
that x € Vars(Co). 


Next we show that Core(C, Xo) < Co. From this, it follows that 
Vars(Core(C, Xg)) < Vars(Co) = CoreVars(C, Xo). 


To prove Core(C, Xo) < Co, we show that Co has the closure properties 
(C-Base) and (C-Srep). 


1. Ifx>t € C, FV(t) = Ø and x € Xo, we have x € CoreVars(C, Xo) by 
(V-BaseE), hence x>t € Co by definition. 


2. Let x>t € C with FV (t) #0 and 
Yx’ € FV (t). Def (x) N Co # 0. 


Then 
FV (t) < Vars(Co) > CoreVars(C, Xo). 


Hence, x € CoreVars(C, Xo) by property (V-Ster), which means that x> t € 
Co by definition of Co. 


o 


Lemma 7.3. Let C be a constraint system and Xo < X be a set of variables. Then 
the following statements are equivalent: 


(1) x>=t € Core(C, Xo) 
(2) (FV(t) =@Ax € Xo) V (FV(t) #0 A FV(t) € CoreVars(C,Xo)) 
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Proof. (1) == (2) Assume x>t € Core(C, Xo). Then either FV(t) = 0 
and x € Xo or FV(t) + @ and Vx’ € FV(t). Def (x) N Core(C, Xo) # 0. In 
the former case, (2) holds trivially. In the latter case, we conclude 


Yx’ € FV(t). x’ € Vars(Core(C, Xo)), 
which is, due to Lemma 7.2, equivalent to 
Yx’ € FV(t). x € CoreVars(C, Xo). 


(2) == (1) We prove the claim by case distinction. 
1. Assume that 


x E€ X9 AFV(t) = 0. 


Then x>t € Core(C, Xo) by (C-Base). 
2. Assume that 


FV (t) + 0 A FV (t) C CoreVars(C, Xo). 
With the definition of Vars and Lemma 7.2, this implies 
Yx’ € FV (t). Def (x’) NCore(C, Xo) #0. 


Thus x>t € Core(C, Xo) by (C-Step). 
oO 


Core(C, X) only eliminates useless constraints. Therefore, the least solution 
of Core(C, X) must coincide with the least solution of C on the whole 
variable set. 


Lemma 7.4. Core(C, X) has the same least solution as C. 


Proof. First, we show that the two least solutions must coincide on 
Vars(Core(C, X)). 

It is clear that Ifp(Feore(c,x)) < Lfp(Fe), since Core(C, X) CC. 

Next, we observe 


(7.3) Vx € X \ Vars(Core(C, X)). 1 fp(Ecore(c,x)) (x) = B. 
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The reason is that by definition, Core(C, X) has no defining constraints for 
variables outside of Vars(Core(C, X)). 
Finally, we show 


(7.4) Ifp (Fe) <Ifp (Fcore(C,x)) 
by fixed-point induction (cf. Corollary 2.7). 
Let 


de 
P zf w:XoLl|lyps Lfp(Ecore(C,x))}- 


It is easy to see that const(®) € P and that P is closed under arbitrary joins. 
It remains to show that F is also closed under Fe. For this, it suffices to 
show 


Vy € P. Yx>t EC. INCy) < Ifp(Fcore(c,x)) (*) 
So let y € P and x>t € C. We have to show that 
(7.5) [t] (y) < [t] (Ifp (Fcore(C,X) )) <Ifp (Feore(C,X) ) (x). 


This follows from the two properties 


(7.6) Ey) < [El (Ifp(Fcore(c,x))) 
and 
(7.7) [tH (fp (Feore(c,x))) <Ifp (Ecore(C,X) ) (x), 


which we are going to show in the following. 

(7.6) By our assumption that y € P, we have in particular 
Ya! € FV (1). W(x) < If (Fcore(cx)))- 

From this, (7.6) can be shown using Lemma 2.10. 


(7.7) We distinguish two cases: 


1. x2t € Core(C, X): Then (7.7) holds because Ifp(Feore(c,x)) is. a solution 
of Core(C, X). 
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2. x>t € Core(C, X). Then it must be the case that 
FV(t) #0A Av’ € FV(t). x’ € X \ Vars(Core(C, X)), 


since otherwise the closure properties of Core(C, X) would immediately 
imply x>t € Core(C, X). 
But then, due to (7.3), there must be one x’ € FV(t) with 
Ifp (Ecore(C,X) ) (X) =R. 
Now, (7.7) follows with (7.2) and (7.1). 


Now I want to consider how Core behaves for Xọ + X. 

The following lemma shows that Core(C, Xo) can be obtained by first 
computing Core(C, X) and then restricting the variables to Xo. The first 
step eliminates all constraints that do not contribute anything, while the 
second step eliminates all constraints that may contribute to the solution 
but depend on variables not in Xo. 


Lemma 7.5. Applying Core(_, Xo) toC is the same as applying it to Core(C, X): 
(7.8) Core(C, Xo) = Core(Core(C, X), Xo). 


Proof. First, we observe that Core(C,X) is a subset of C and Core is 
monotone in its first argument. This implies 


Core(C, Xo) 2 Core(Core(C, X), Xo). 


It remains to show “S”. For this, we show that Core(Core(C, X), Xo) has 
the properties (C-BAse) and (C-Srer) with respect to C and Xo. 


1. Let x>t € C with FV(t) = Ø and x € Xp. Then in particular x € X. 
Hence, by applying (C-Base) to x>t € C and x € X, we get 


x>t € Core(C, X). 


Then we apply (C-Basg) to x € Xp and x>t € Core(C, X) and get our 
desired result 


x>t € Core(Core(C, X), Xo). 
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2. Letx>t € C with FV(t) + Ø and 
Vx’ € FV(t). Def (x’) MCore(Core(C, X), Xo) # 0. 


Since Core(C, X) c C and Xp < X, and due to the monotonicity of Core, 
we have 
Core(Core(C, X), Xo) < Core(C, X), 


so that we can weaken the second condition to 
Yx’ € FV(t). Def (x) NCore(C, X) #0. 
With (C-Ster) for C and X, we conclude 
x>t € Core(C, X). 


Another application of (C-Ster), this time for Core(C, X) and Xo, finally 
yields 
x>t € Core(Core(C, X), Xo) 


o 


The intuition of Core is that the least solution of Core(C, Xo) coincides 
with C on a relevant part of X, namely CoreVars(C, Xo). But this is not 
true for every choice of Xo. 


Example 7.6. Assume that Expr(F , X) contains appropriate function symbols 
for expressing subsets of {a,b} and set constraints over these sets. Moreover, 
assume an appropriate interpretation. 


1. Consider the following constraint system C: 


x2Qy 
xD {a} 
y 2 {b} 


Now consider Xo = {x}. Then we get 
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2. Consider the following constraint system C”. 


y2x 
xD {a} 
y 2 {b} 


Now consider X = {x}. Then we get 


Core(C’,X 
CoreVars(C’,X 


The two examples each highlight a characteristic problem that prevents 
Core(C, Xo) from exhibiting the same least solution as C, if Xo is not chosen 
appropriately. 

In the first example, the problem is that the constraint x 2 y is not contained 
in Core(C,Xo), as it does not depend on a constant constraint that defines 
x (or, more generally, a variable from Xọ). 

In the second example, y 2 {b} is not included in Core(C’, Xj) because y 
does not belong to X}. 

An appropriate choice of Xp hence ensures two things: 


1. Every constraint in Core(C, Xo) transitively depends on a constant 
constraint defining some variable from Xo. 


2. If a variable v € CoreVars(C, Xq), then all constant constraints defining 
v are contained in Core(C, Xo). 


In the following, I introduce definition-completeness as a property of con- 
straint systems that ensures the coincidence of least solutions. After that, I 
consider conditions on variable sets that ensure the definition-completeness 
of the corresponding Core set. 


Definition 7.7. Co <C is called definition-complete if it has the property 


Vx2teC.Def(x)NCo #0 = Def (x) <Co 
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Definition-completeness is indeed sufficient for the coincidence of the least 
solutions on the core-variables. This is formally stated by Theorem 7.9. 
Before I can prove that, I need a technical lemma that enables me to perform 
the fundamental proof steps. 


Lemma 7.8. If Co a Core(C, Xo) is definition-complete, then 
(7.9) y SVars(Co) Ifp(Fcy) = Fey) SVars(Co) Fo(Ifp(Fey)) 


(7.10) Ifp(Fc) SVars(Co) Ifp(Ecy) 


Proof. First, assume that (7.9). Then we can show (7.10) by fixed-point 
induction (Corollary 2.7). Let 


de 
P = fp: X>L|p SVars(Co) Lfp(Feg)}- 


We need to show that const(&) € P, that P is closed under arbitrary joins 
and that P is closed under Fç. The first two statements can easily be seen 
and the third claim is proven by (7.9). 
Now we prove (7.9). Assume Y <vars(Cq) LfP(Fc,)- We need to show that 
Fey) SVars(Co) Fe(lfp(Fc,)) and for this it is enough to show 

Vx>t eC. xE Vars(Co) — IY) < Ifp(Fc) (x). 


Solet x>t € C with x € Vars(Co). Since Cg is definition-complete, it must be 
x>t € Co. By Lemma 7.2 and Lemma 7.3, it follows that FV (t) < Vars(Co). 
But according to our assumption this means that 


Vx" € FV(t). p(x) <Ifp(Ec,)@"). 


Using Lemma 2.10, this entails 


(x) LIY) < LMF p(Fey)), 
and because I fp(Fc, ) satisfies x > t we have 
(xx) Ip (Fog) < Lip (Fey) (x). 
From (x) and (xx) we get 

LIH) < Lfp (Fog) (x), 


as desired. oO 
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Theorem 7.9. If Core(C, Xo) is definition-complete, then 


(7.11) Ifp (Fe) =CoreVars(C,Xo) lfp (Feore(C,Xo)) 
Proof. With Co = Core(C, Xo), we need show 

(7.12) Ifp(Fe) SVars(Co) Ifp(Ecy) 

(7.13) Ifp(Fcy) SVars(Co) Ifp(Ec) 


With the given assumptions, (7.12) follows directly from Lemma 7.8. 
Hence, it remains to show (7.13), which can be justified as follows. 

Core(C,Xo) is a subset of C. Therefore, every solution of C is a 
solution of Core(C,Xq). Hence, Ifp(Fc) is a solution of Core(C, Xo). 
Since Ifp(Feore(C,X,)) 18 the least solution of Core(C, Xo), this implies 
Lfp(Feore(C,Xp)) < Ifp(Fe). Clearly, this also holds when restricting to 
CoreVars(C, Xo). m) 


Theorem 7.10 states conditions on Xg that characterize definition- 
completeness. This is basically a formalization of the intuition given 
in Example 7.6. 


Theorem 7.10. Core(C, Xo) is definition-complete if and only if it satisfies the 
following two conditions: 


(i) Yx>t € C. x € CoreVars(C, Xo) AFV(t) = 0 
=> xE Xo 


(ii) Vx>teC. Vx’ € FV(t). x € CoreVars(C, Xo) 
=> x € CoreVars(C, Xo) 


Proof. We show the two directions separately. 


1. Assume that Core(C, Xo) is definition-complete and let x>t € C and 
x € CoreVars(C, Xo). Then x € Vars(Core(C, X9)) by Lemma 7.2, which 
means that Def (x) N Core(C, Xo) + Ø. Since Core(C, Xo) is definition- 
complete, this entails that x>t € Core(C, Xo). 


Now we can show (i) and (ii) by considering the two cases FV (t) = Ø and 
FV(t) #0: 
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e IfFV(t) = 0, x>t € Core(C, Xo) implies x € Xp by Lemma 7.3, which 
shows (i). 

e Assume that FV(t) + Ø. Together with x>t € Core(C, Xo), we get 
FV(t) < CoreVars(C, Xo) by Lemma 7.3. This shows (ii). 


2. Assume that (i) and (ii) hold and let x € X with 
Def (x) N Core(C, Xo) + 0 Ax>t € Def (x). 


Together with Lemma 7.2, this implies x € CoreVars(C, Xo). 


Now we show x >t € Core(C, Xq) by case distinction on whether FV (t) = 0 
or not. 


e If FV(t) = 0, then with x € CoreVars(C, Xo) we get x € Xo by (i). But 
this means x >t € Core(C,Xo) due to (C-Base). 


e If FV(t) #0, then with x € CoreVars(C, Xo) we get 
Yx’ € FV(t). x’ € CoreVars(C, Xo) 
by (ii). But by definition and Lemma 7.2 this is the same as 


Yx’ € FV (t). Def (x) N Core(C, Xo) + 0. 
This implies x >t € Core(C, Xo) by (C-Ster). 
oO 


Now I am ready to present Algorithm 8, a variant of Algorithm 3 that also 
uses a worklist approach to compute the solution of a given constraint 
system, but at the same time also performs a reachability analysis. More 
specifically, Algorithm 8 takes a set X, of variables and, starting with Xo, 
traverses the constraint dependency graph from usage to definition. 

In the following, I state and prove a correctness result for Algorithm 8. 
This proof is a a variation of the correctness proof for the ordinary worklist 
algorithm [130] that I already mentioned in chapter 2. This proof is 
combined with correctness arguments for the reachability parts taken from 
Takai [160]°°. 


35Tamai [160] also considers integrating reachability into graph problems that can be 
encoded as constraint systems. They propose an algorithm whose worklist policy is the 
same as the one for Algorithm 8 and their correctness proof works similarly as the proof of 
Theorem 7.11. However, Tamai does not encode unreachability explicitly into the lattice. 
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Algorithm 8: A variant of the worklist algorithm where the items 
taken off the worklist have just been updated but changes have 
not been propagated yet 


Input: a monotone constraint system C with interpretation over 
the variables X, a set Xp < X of initial variables 
Result: a function X — L with properties as stated in The- 
orem 7.11 
1 A < const({R) 
2 foreach x>t € C s.t. x € Xo AFV(t) = Ø do 
3 | Alx) — A(x) Ut (A) 
4 W e WU {x} 


5 while W #0 do 


6 | x remove(W) 

7 | foreach x’ > t€ C such that x € FV (t) do 

8 if Yy € FV(t). y#x = A(y) +m then 
9 old — A(x’) 

10 A(x’) — A(x’) U [Et] (A) 

11 if A(x’) # old then 

12 Ik We Wuß’) 


13 return A 


For abbreviation, I define 
d 
Co =! Core(C, Xp) 
def 
Vo = Vars(Co) 


Theorem 7.11. Algorithm 8 always terminates and upon termination, we have 


Ifp(Fop)(x) fx € Vo 


= otherwise. 


(7.14) A(x) = | 


Moreover, if Co is definition-complete with respect to Core(C, X), then 


(7.15) A =Vo lfp (Feore(C,x)) =Ifp(Fc) 
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Proof. First, assume that (7.14) has been shown and that Co is definition- 
complete with respect to Core(C, X). Then 


A =q; Ifp(Foy) { (7.14) } 
=, lfp (Fcore(c,x)) { Theorem 7.9 } 
= 1fp(Fe). { Lemma 7.4 } 


It remains to show (7.14). This follows from the following three statements: 
(A) Algorithm 8 terminates. 
(B) Algorithm 8 maintains the invariant 
{x € X| A(x) #B} CV 
and upon termination, we have 


{x € X | A(x) +B} = Vp. 


(C) Algorithm 8 maintains the invariant 


A < Ifp(Fe,) 


and upon termination, we have 
A =y; Lfp(Feg)- 


For a proof of (A), see Lemma 7.12. (B) is going to be shown in Lemma 7.13 
and, finally, I will prove (C) in Lemma 7.14. Oo 


The remainder of this section consists of the three statements (A), (B), and 
(C) that were left to show in the proof of Theorem 7.11. 


Lemma 7.12. Algorithm 8 terminates. 


Proof. It is sufficient to show that the main loop in the lines 5-13 is only 


d 
traversed finitely often. For this purpose, we define T 2 (X > L) x 2%, 
Elements of T can be used to represent the state which is maintained by 
the algorithm: The first component is the currently computed solution and 
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the second component is the current worklist. Moreover, define on T the 
relation 


def 
(A1,W1) Sr (Az,W2) & Ai >(x1) 42 V (A1 = A2 A W1 © W2) 


Then <r is a partial order and satisfies the descending chain condition, 
since X — L satisfies the ascending chain condition and 2% is finite. Let 
(A, W) € T be the state of the algorithm at any time. 

Now consider an iteration of the main loop. Let (Agig,Woiq) and 
(Anew, Wnew) be the state at the beginning and end of this itera- 
tion, respectively. Now two cases are possible and we show that 
(Anew, Wnew) <T (Aola, Wold) must hold in either case. 

First, assume that Aog has not been changed in the iteration. Then we 
have Anew = Aig and the iteration has removed exactly one element of 
Woiq and did not add any elements to it, ie. Whew & Woig, which means 
that 


(Anew, Whew) <T (Ada, Woia) 


in this case. 

Now assume that Aoig has indeed been touched. Then this can only have 
happened by executing line 10, which changes Ay]; upwards. Hence, we 
have Agig(x) < Anew(x) for some x € X. This entails 


(Anew, Whew) <T (Abia, Woa), 


as desired. 

Now we have seen that (A, W) becomes strictly smaller in each iteration 
of the main loop. Hence, since the partial order (T, <r) satisfies the 
descending chain condition, the main loop can only be traversed finitely 
often, as desired. oO 


Lemma 7.13. 1. Algorithm 8 maintains the invariant 


(x € X| A(x) + B} E Vo. 


2. Upon termination, we have 


{x € X | A(x) #8} = CoreVars(C, Xo). 
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Proof. 1. Ford: X —> L define 


dom(p) I (x eX | w(x) #0). 


Then we have to show that 
(Inv) dom(A) < Vo 


holds after the execution of each statement in Algorithm 8. We only need 
to consider executions of line 3 or 10, since all the other statements leave 
A unchanged and therefore maintain (Inv) trivially. 

So consider any execution of line 3 or 10 for a given constraint x > t. Let 
Aq be the value of A before this execution, Anew be the value of A after 
this execution. 


Assume that (Inv) holds for Ayıg- 


If the considered execution does not change A, (Inv) is maintained trivially. 
So assume that the considered execution indeed changes A. In this case 
we have 


dom(Anew) = dom(Apia) Y {x}, 


i.e. we must show that x € Vo. 


For an execution of line 3, this is indeed the case: This follows by (V-Base), 
because line 3 is executed only if x € Xp and FV(t) = 0. 


Next consider any execution of line 10. Then it must be the case that FV (t) 
is not empty. Moreover, since the considered execution of line 10 changes 
A, it cannot be the case that A,jg(x) = &. Otherwise, [t] (A4) would be 
X in the case that x € FV (t), because of (7.2). Together with line 8, this 
ensures that FV (t) c dom(A,jq). By (Inv), this means that 


Vy € FV (t). y € Vo. 


By Lemma 7.3, this entails x > t € Co, or, equivalently, x € Vo. 


2. By induction on x € Vo, we show that for every x € Vo, A(x) is written 
to at some point in Algorithm 8. 
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(V-BasE) The initial loop applies every constraint x > t with x € Xy and no 
variables on the right-hand side. Since A is only changed upwards, and 
because of (7.2), this guarantees that upon termination, we have A(x) #® 
for every x € Xp for which there is a constraint x > t with FV (t) = 0. 


(V-StEP) Consider a constraint x > t such that 
O + FV(t) € Vo. 


By induction hypothesis, we may assume that for all y € FV (t), A(y) is 
written to for the first time at some point in Algorithm 8. Since FV(t) # 0, 
we may further assume that there is an iteration in which this happens 
for the last yo € FV(t). Particularly, at the beginning of this iteration, 
A(y) + X for all y € FV(t) \ {yo} and A(yo) = X and at the end of this 
iteration A(y) + x for all y € FV(t). This means that A(yo) is changed 
in this iteration and since yo € FV(t), x is added to W. Hence, at the 
end of the iteration, x € W. Since Algorithm 8 terminates (Lemma 7.12), 
x is eventually considered in some later iteration. We may assume that 
A(x) = ® at the beginning of this iteration, since otherwise our claim 
follows trivially. Furthermore, we notice that 


Vy E€ FV(t). A(y) + m 


is maintained until Algorithm 8 terminates. So, this property holds 
particularly in the iteration in which x is removed from the worklist. 
During this iteration, x > t is eventually considered. Again, we assume 
that A(x) = M until x > t is considered, since otherwise there is nothing to 
show. Now, when x > t is eventually processed, the check in line 8 passes 
and A(x) is written to for the first time. 

Oo 


Lemma 7.14. 1. Algorithm 8 maintains the invariant 
A < lfp(Fco). 
2. Upon termination, we have 


A =Vo Ifp(Ecy)- 


Proof. We show the two statements separately. 
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1. We have to show that 


(Inv) A<Ifp(Fc,) 


is maintained by every execution of each statementin Algorithm 8. We only 
need to consider executions of line 3 or 10, since all the other statements 
leave A unchanged and therefore maintain (Inv) trivially. 


So consider any execution of 3 or 10. Let x > t be the constraint that 
is applied. First, we notice that line 3 is only executed if x € Xo and t 
contains no variables. Hence, x>t € Cg. Secondly, we see that line 10 is 
only executed if 

Vy € FV(t). Aly) + R, 


and this implies, according to the invariant in Lemma 7.13, that FV (t) < Vo. 
Hence, in both lines 3 and 10 we have x>t € Cg and therefore 


(x) Lfp(Feg)(x) 2 [tI fp(Fey))- 


Let Ag be the value of A before the execution and Anew be the value of 
A after the execution of line 3 or 10. Then we have 


(xx) Anew (x) = Aoalx) u [t] (Aoa). 


Now assume that (Inv) holds for Agjg. To show (Inv) for Anew, we only 
need to consider Anew(x) since the rest is left unchanged. 


Then, we can argue as follows: 


Anew(x) 
= Aoa (x) UME (Agia) { (xx) } 
<I fp(Foy)(x) UTE fp (Fey )) { (Inv), Lemma 2.10 } 
= Ifp(Feg) (x) { (x) } 


2. We show that the main loop of Algorithm 8 maintains the invariant 
(Inv) Vx2teC. x €dom(A) 
A FV(t) c dom(A) 
AFV(t)AW=0 
=> A(x) = EA). 
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This is sufficient: Upon termination, W is empty. Hence, the following 
property holds: 


Yx>t €C. x €dom(A) A FV (t) c dom(A) => A(x) > Tt] (A). 
Using Lemma 7.13, this is equivalent to 
(7.16) Yx € Vo. Vx>t EC. FV(t) E Vo => A(x) 2 INA). 


Now consider any constraint x>t € Core(C, Xo). If x € Xo and FV(t) = 9, 
then (7.16) trivially implies that A satisfies x > t. Next, consider the case 
that FV (t) #0 and 


Vy € FV (t). Def(y) A Co #0. 


ByLemma 7.3 and Lemma 7.2, it follows that FV (t) < Vo. Again, by 
application of (7.16) we see that x > t is satisfied by A. 

It remains to show that (Inv) holds at the beginning of the main loop and 
is maintained by each of its iterations. 

(Inv) holds just before the first iteration of the main loop: In the ini- 
tialization loop, A was only updated for x € Xg and only for those 
constraints x > t where FV (t) = 0. Hence, if x>t € C with FV(t) AW = 0 
and A(x) + x and Yy € FV (t). A(y) + m, it must be the case that x € Xy 
and FV (t) = @. Due to the initialization, A(x) > [t](A) holds since this 
was ensured by the assignment in line 3 and could not be invalidated by 
any other execution of this line. 

(Inv) is maintained by any iteration: Let i be some iteration of the main 
loop. Let Aola and Wq be the values of A and W at the beginning of this 
iteration and Anew and Wyew the respective values at the end. Assume 
that (Inv) holds at the beginning of i: 


(Invpre) Yx>teEC. x €dom(Apgiq) 
A FV (t) < dom(Abig) 
AFV(t) 0 Wog = 0 
=> Aboia(x) = ENA). 


Now consider a constraint x>t € C with Ayew(x) + Band FV (t) N Whew = 
O and FV(t) < dom(Anew). We have to show Anew(x) = [Et] (Anew). 
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First, we make two important observations: Firstly, it must be the case that 


(7.17) Anew 2 Apia: 


Secondly, from FV (t) A Whew = 0, we can conclude 


(7.18) Vy € FV (t). Anew(y) = Aoa (y). 


Now we make a case distinction: 


a) Agia(x) = [lAo ). Then we can show our claim as follows: 


Anew (x) 
> Apia (x) { (7.17) } 
> [El Avra) { assumption } 
= [t] (Anew) { (7.18), Lemma 2.10 } 


b) Aoia(x) Z (Aoa). Then because of (Invpre), one of the following 
statements must be true: 


(7.19) Ay € FV (t). Ayg(y) = B 
(7.20) Aold = X 
(7.21) FV (t) A Wog # 0 


We consider each of these cases separately. 


e For (7.19), we argue as follows: 


Lt] (Anew) 
= [t] Aoa) { (7.18) } 
= { (7.2) } 
< Anew (x) { (7.1) } 


e If (7.20) holds, then line 10 must have been executed for x > t. After- 
wards, A(x) could only have changed upwards, so we can conclude: 


Anew (x ) 
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> Agia(x) ULE (Agi) { see above } 
> lAa) { properties of U } 
= [H] (Anew) { (7.18), Lemma 2.10 } 


e If (7.21) is true, then a variable x’’ was removed from W and every 
x’ > t’ with x” € FV(t’) was considered and A(x’) was updated if 
needed. Since x” € Wag and FV (t) N Woiqg # @ and FV (t) N Whew = 0 
and x” was the only element which was removed from W, it must be 
x” € FV(t). Hence, line 10 was particularly executed for x > t. Now 
we can argue just as in case (7.20). 


oO 


7.2 Integration of Interprocedural Slicing and 
Interprocedural Data-Flow Analysis 


This section gives an outline of sections 7.3 and 7.4, in which I am going to 
apply the results from section 7.1 to the constraint systems that I showed 
and discussed in chapter 6. 

Section 7.3 is dedicated to the functional approach, while section 7.4 
considers the call-string approach. 

For my purposes, I fix a data-flow framework F = (G, L,F, pọ). Moreover, 
I fix a set Src C N of source nodes. 

The goal of the following sections is to derive algorithms that compute a 
VP-correct solution on the forward slice of Src. I do this by instantiating 
Algorithm 8 for solving relevant parts of the constraint systems that we 
saw in chapter 6. 

To be able to handle unreachability, I adjoin F with an element m and 
extend F and [.] like outlined in section 5.3 and section 6.1, respectively. 
In particular, this is compatible with (7.1) and (7.2), so that I can actually 
apply the results from section 7.1 to the constraint systems chapter 6. 
Next, I want to describe a recurring theme of the following sections. For 
simplicity, I exclude the call-string approach for the moment. I will handle 
its specifics in section 7.4. 

Consider a constraint system Cp corresponding toa set of paths P < Pathsc. 
Then I want to use an instantiation of Algorithm 8 to compute a solution 
Ap along the paths from P such that 
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Y(s,t) e VP’. Ap(s,t) = Ifp(Cp)(s, t), 
where 
yP) a {(s,t) € NXN | Pathsg(s,t) NP # O}. 


According to Theorem 7.11, Algorithm 8 computes such an Ap for V 
CoreVars(Cp, Xo), where Xo € X is chosen appropriately and Core(Cp, Xo) 
is definition-complete in Core(Cp, X). Hence, the general steps of the 
following sections will be 


(P) 
0 


1. specify Xo, 
2. instantiate Theorem 7.11, 


3. show that 
CoreVars(Cp, Xo) = {(s,t) E N x N | Pathsg(s,t) NP + Ø} 
and, finally, 


4. show that Core(Cp,Xo) is definition-complete in Core(Cp, X). 


7.3 Functional Approach 


I want to remind the reader of Constraint System 6.4, which was defined 
as follows: 
Xasc(s,n) #8 Xpesc(n,t) +m 


Xyp(s,t) 2 Xpesc(n,t) o Xasc(s,n) 
Given X,sc and Xpesc, a valid-paths solution Xyp could be obtained by 
evaluating the equation 


(VALID-SOL) 


(7.22) Xvp(s,t) = | | Xpesc(n,#) © Xasc@,n). 
neN 


One direct and naive strategy would be to first compute both X,4sc and 
Xpesc on the whole set Nx N and then use these functions to evaluate 
(7.22). However, such an approach would perform a lot of unnecessary 
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work: In fact, one only needs to compute Xpgsc (n,t) o Xasc(s,n) for those 
s,n,t € N for which s € Src, Xasc(s,n) + Band Xpesc(n,t) + m. 

We can reduce the amount of unnecessary work by first computing X,4sc 
on dom(ASC) and then use X,sc to compute an integral part of Xyp. 
Roughly, the idea is to compute a solution Xyasc such that Xyp can be 
written as Xasc U Xnasc- For this, I need to introduce another set of paths, 
the non-ascending paths. 


Definition 7.15. n € Pathsg(s,t) is called non-ascending if n can be written 
AS Ty + Tp such that 


(i) T E€ ASC(s,n) 
(ii) m € DESC(n, t) 
(iii) n € Nean 
(iv) nn ¢ ASC(s, t) 


I denote the set of non-ascending paths from s to t with NASC(s, t). 


Definition 7.15 is motivated by the fact that any valid path is either 
ascending or non-ascending. This is formalized by Lemma 7.16 and 
Remark 7.17. 


Lemma 7.16. If n € VP(s,t), then either of the following is true: 

1. ne ASC(s,t) 

2. There are c € Negi, T1 E ASC(s,c) and T2 € DESC(c, t) such that n = nı - 
72 


Proof. Let n € VP(s,t) \ ASC(s,t). By Theorem 5.22 there is i € range(1) 
such that n“ € Left(E), n=! € Right(E) and rn € Enq. Define 


d ‘ 
mel sre(n'), 
d ; 
T ef n“, and 
def èi 
TM, = n”. 
Then c € Negi, since 7 is an outgoing call edge of rÍ. Moreover, because 
mt € Pathsc(s,t), we have m1 € Pathsg(s,c) and 712 € Pathsg(c, t). Lastly, by 
Theorem 5.39, we have m1 € Val(E) and m2 € Val(E). In summary, 711, 72 
and c have the desired properties. m 
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Remark 7.17. ne NASC(s, t) if and only if n € VP(s,t) \ ASC(s,t). 


u 


Proof. “ <=” is covered by Lemma 7.16. 
So let n € NASC(s,t). Then n € VP(s,t) by Theorem 5.30 and since 
mt € Pathsg(s, t). Furthermore, m ¢ ASC(s,t) by Definition 7.15. Oo 


Lemma 7.16 can be applied as follows: Since any valid path is either 
ascending or non-ascending, we can obtain a valid-paths solution by 
joining an ascending-paths solution with a solution Xy,sc that merges 
over all non-ascending paths. 

The rest of this section is dedicated to computing a valid-paths-solution 
using the approach that I just sketched. First, subsection 7.3.1 considers the 
computation of the least same-level solution ASL), Then, subsection 7.3.2 
shows how to use a same-level solution such as A'S") to compute the least 
ascending-paths solution Al4SC), After that, subsection 7.3.3 is dedicated 
to the extension of a given ascending-paths solution like ASC) along 
the descending paths to obtain the least non-ascending-paths-solution: 
First, a constraint system is given that characterizes non-ascending-paths 
solutions and then the usual scheme is used to compute the least non- 
ascending-paths solution ANASC), 

The last three subsections consider the combination of AST) and 
A\NASC) | Subsection 7.3.4 shows that joining ALASO) and A\NASC) actually 
yields a valid-paths-correct solution, provided that ALASO) and ANASO) 
are correct relative to their respective path sets. Moreover, it compares 
the solution obtained by this approach with the original least valid-paths 
solution. After that, subsection 7.3.5 integrates all the sections before in a 
simple algorithm and shows its correctness. This algorithm uses the same 
ideas as the two-phase slicer by Horwitz et al. that I already discussed 
in chapter 3, however there are still some differences. Subsection 7.3.6 
explores these differences, modifies the algorithm from subsection 7.3.5 in 
such a way that it essentially becomes the two-phase slicer and sketches a 
correctness proof. 


7.3.1 Computing the Same-Level Solution 


In the following, I consider the constraint system from Constraint Sys- 
tem 6.1, which I denote with cl), 
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I define 

de 
(7.23) 2” = {(s,s) | s € Nentry} 
(7.24) CD F Core(c(S)), xD) 
(7.25) VS) 2f Corevars(c'S"), xl) 


Algorithm 9 is an instantiation of Algorithm 8 for the constraint system 


Gi), using x as set of initial variables. 


The loop in lines 2-4 corresponds to the initialization loop in Algorithm 8. It 
processes all constant constraints in Constraint System 6.1 whose left-hand 


side isinX (SD), 


The loop in lines 5-18 corresponds to the main loop Algorithm 8. All 
constraints x > u with (s,t) € FV (u) are enumerated and the respective 
ALSH) (x) is updated, just like in Algorithm 8. However, the constraint 
enumeration loop in Algorithm 9 is split into three parts. 

The first of these parts, in lines 7-9, enumerates all constraints of the form 
SL-SOL-(11). 

The other two parts are dedicated to constraint sL-soL-(111). This is because 
Algorithm 9 propagates from the right-hand side of a constraint to its 
left-hand side. In contrast to sL-soL-(1), there are two free variables on the 
right-hand side of st-so.-(111)-constraints, so that (s,f) can occur at two 
positions. To illustrate this, let us take a look at such a constraint. It has 
the form 


XsL(s,t) = fer © Xs-(No, 11) © fean ° Xsi(S, n) 


with n a No, Ny = t and (ecall,Eret) € ©. 

Hence, each of the two variables on the right-hand side of a rule have to 
be considered separately. 

The loop in lines 10-13 takes care of the case that the variable currently 
processed is (s,n) in the above situation, whereas the loop in lines 15-18 
takes care of the other case: Here, the variable currently processed is 
(no, n1) in the above situation. 

In summary, the two loops enumerate all constraints c of the form 
SL-SOL-(111) with (s,t) € FV(rhs(c)). 
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Algorithm 9: Algorithm for computing the least same-level 
solution 
Input: a data-flow framework instance F = (G, L, Fg, p) as de- 
scribed on page 295 
Result: least same-level solution for F , as stated in Theorem 7.18 
ASL) — const (m) 
foreach s € Nentry do 
AS) (s,s) < id 
W=WU{(s,s)} 


5 while W#0do 


A WO N e 


6 (s,t) — remove(W) 
7 foreach ft’ € N s.t. t >’ nee Ein. do 
8 ASD (5, 1") — AD) (st) U fe o ASL) (s,t) 
9 | W- WU ((s,t’)} if ASL) (s, t’) has changed 
10 foreach (e.,e,)E® s.t. t a no Any £5 # a ASL) (no, n1) + & do 
11 slSol — fo, o A'S") (no,n) © fes 
12 AD (5,1) AD (s, t”) Lis o AS) (s, t) 
13 | We WU ({(s,t’)} if ASL) (s, t’) has changed 
14 | foreach (e,e,)€@s.t.aSsAt5 bdo 
15 foreach u € Nentry S-t. ASL) (u,a)#® do 
16 slSol — fe, o ASL) (s, t) © fo. 
17 ASL) (u,b) — ASL) (u,b) U slSol o A'S) (u,a) 
18 W e WU {(u,b)} if AS") (u,b) has changed 


19 return A(SL) 


Now that the reader is convinced that Algorithm 9 is an instantiation of 
Algorithm 8, I want to instantiate the correctness result of Algorithm 8 for 
Algorithm 9. 


For the moment, I assume that ee is definition-complete with respect 


to C(SL), Then I can use Theorem 7.11 to prove the following correctness 
result. 
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Theorem 7.18. The following statements hold: 
1. Algorithm 9 always terminates and upon termination, we have 
. SL 
7.26) AD = B pE) t) Fey 
X 


otherwise 


2. Upon termination, AS") is always (SL, VS") correct. 
3. If F is u.d., then A) is (SL, VS) precise. 
Two things are left to do. Firstly, we have to characterize V 


(SL) 
0 


appro- 
is indeed definition- 


(SL) 
0 


priately and secondly, we have to show that C 


complete with respect to CS), 


(SL) 
0 
C(SL) is defined along the same-level paths of G, same-level reachability 
(SL) (SL) 
0 0 
into account, we can only expect (s,t) € ven if s € Nentry- 


We start with the characterization of V% ~. Ideally, considering the fact that 


should be the right property to characterize CY “~. Moreover, taking X 


Lemma 7.19 formally confirms that V en indeed has the desired charac- 
terization. 


Lemma 7.19. yt) and CoreVars(C, N x N) can be characterized as follows: 


SL) 


(7.27) VEN = ((5,t) € NXN | SL(s, t) #0} A Nentry XN 


(7.28) CoreVars(C, N x N) = {(s,t) €E NXN | SL(s, t) + 0} 


In particular, V (Sh) can be obtained from CoreVars(C, N x N) by restricting the 
first components to Nentry: 
(7.29) VS") = CoreVars(C,N x N) N Nentry XN 


Proof. The claim (7.29) follows directly from (7.27). 

It remains to show (7.27) and (7.28). We only show (7.27), since the proof 
for (7.28) is very similar. 

We prove (7.27) by showing the two subset relations separately. 
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1. In order to prove “2”, we show 


Yr € SL.Y(s,t) € Nentry X N. 7 € SL(s,t) 


= (s,t) e VOU 


by induction on n € SL. So let n € SL and (s,t) € Nentry X N such that 
ne SL(s,t). 


a) Suppose that n = e. Then we have s = ¢ and s € Nentry, so that 
(s,t) = (s,s) € xen, By sL-soL-(1), C(SL) contains the constraint 


X(s,s) > id, 


which does not have variables on the right-hand side. Hence, (s,s) € 
CoreVars (C'S), xD by (V-Base). 


b) Assume that n = n’ -e, where e € Eina, t’ > tand rn’ € SL(s, t’). Since 
n’ € SL(s,t’), we can apply the induction hypothesis to n’: s € Nentry 
implies that 


(st) VEY. 
By sr-sor-(), C (SL) contains the constraint 


X(s,t) 2 feoX(s,t’). 
Since (s,t’) € V (S1) we may apply (V-Ster) and conclude 
(3,2) «VE, 


c) Suppose that 
n=n:- Ccall ` n” eret 


with n’ € SL(s,n), n” € SL(no,n1), n “cayi no, nı tt and (€caits eret) € ®. 


We apply the induction hypothesis to n’ € SL(s,n) and conclude from 
se Nentry that 


(7.30) (sn) VO, 


302 


7.3 Functional Approach 


Moreover, note that ng has an incoming call edge. Hence, we have 
no € Nentry. With n” € SL(no, n1) we can apply the induction hypothesis 
to n” and obtain 


(7.31) (no, n1) € CoreVars(C), x” dy 


Moreover, by sL-soL-(mI), C (SL) contains the constraint 
X(s,t) > fe, ° X(no, n1) © fe all oX(s,n). 


With (V-Ster), we conclude (s,t) € ve from (7.30) and (7.31). 


2. For “C”, we show 


(s,t) € ys) => SL(s,t) + As € Nentry 


by induction over St) = CoreVars(C(S4), x, 
Let (s,t) € yon. Let c € ec with Ihs(c) = (s,t). Our induction 
hypothesis states 


V(x, y) € FV(rhs(c)). SL(x, y) # 0 As € Nentry 
a) Suppose that FV(rhs(c)) = Ø. Then c must be of the form 


Xsı (s,s) > id 


Clearly, SL(s,s) + Ø, since e € SL(s,s). 


b) Suppose that FV(rhs(c)) # 0. Then c is either of the form st-soL-(11) or 
sL-soL-(111). We only consider si-soL-(111), since sL-soL-(1I) is similar. 


So assume that c has the form 


XsL(S,t) = feret © XsL (10,11) © fern Xsı(s,n) 


(SL) 
0 


. Hence, we can apply the induction 


call e 
such thatn ® no, nı B tand (el, eret) € ®. From c € C\” , we conclude 


(s,n) € ven and (no,nı) € ven 
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hypothesis to (s,n) and (no,nı) and yield s € Nentry, T’ € SL(s,n) and 
rn’ € SL(ng,nı). These two paths can be used to obtain 


de 
T = T + cq T” -eret € SL(s,t), 
as desired. 
Oo 


In order to complete the proof of Theorem 7.18, we show the definition- 
completeness of C er with respect to Core(C (SL), N x N). 


Lemma 7.20. cS) is definition-complete with respect to its superset 
Core(CS"),N xN). 


Proof. We use Theorem 7.10. Let c € Core(C(°),NxN) with Ihs(c) € 


ven, Then we have to show 


(7.32) FV(rhs(c)) =0 => Ihs(c) e XS 
(7.33) FV(rhs(c)) #0Ax€EV(rhs(c)) => x € CoreVars(C(°), x.) 
e For (7.32), assume that FV (rhs(c)) = Ø. Then c is of the form 
XsL (s,s) > id 
From Ihs(c) = (s,s) € yt) we get s € Nentry by (7.27). Hence, 
x (SL) 
(s,s) EX > 


e For (7.33), assume that FV (rhs(c)) # Ø. Then there are two possible 
shapes of c. 


1. Let c be of the form sL-soL-(n), i.e. 
Xr (s/t) > feret © Xsi(M0,11) © fean ° Xsi(S, n) 


e e 
withn “ no, n “3 tand (Ecall ret) € ©. 
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From Ihs(c) = (s,t) € vd, we conclude s € Nentry by (7.27). Since 


0 
ce eer, we have 
(x) Xsr(s,n) € CoreVars(C ST), N x N), and 
(xx) Xsr(no,nı) € CoreVars(C(S"),N xN). 


We apply (7.29) and conclude from s € Nentry, (x) and (xx) that 


st), 


Xsr(s,n) € CoreVars(C(S4), x . Moreover, note that ng € Nentry, 


since it has an incoming call edge. Hence, Xsz (no, n1) € ven by 
(7.29). 


With (C-Srer), it follows from (x) and (x~) that c € CS"), and, with 
(V-Ster), (s,f) € ven, This concludes the proof of (7.33) for c. 


2. The argument for the form sı-soL-(1) is very similar. 


7.3.2 Computing the Ascending Solution 


In the following, I consider the constraint system from Constraint Sys- 
tem 6.2, which I denote with C (ASC), 


I define 

(7.34) x = {(s,s) |s € Src} 

(7.35) CAS) Ff Core(c(48C), (ASO) 
(7.36) vr def CoreVars(c 450), x 59) 


Algorithm 10 is a straight-forward instantiation of Algorithm 8 to solve 
Constraint System 6.2 with respect to a function 


Xs, : NxN > Fr. 


This function could have been computed by Algorithm 9, but can also 
have been obtained in any other way. 
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Theorem 7.21 gives a correctness result for Algorithm 10. Similar to 
Theorem 7.18, the first item in Theorem 7.21 directly follows from the 
ASC 
l ) 
complete with respect to C(45©), However, this first item only is concerned 
with the relation between the result of Theorem 7.18 and the least solution 
of C450), In order to get full correctness and precision results, I need 
additional requirements for Xs; relative toa set ¥ CN XN. 

In principle, there are multiple choices for Y. Ijust need to ensure that (a) ¥ 
is large enough so that C(45©) and Algorithm 10 never access Xsz, outside 
of Y and that (b) the output of Algorithm 9 is indeed (SL, Y)-correct. The 
following choice of Y has both properties: 


generic result Theorem 7.11, once I have shown that C is definition- 


ASC) 


de 
(7.37) (no nı) € ¥ & (no n1) € Nentry x Nexit 
Adn, t € N. Aleca, eret) € ®. n = No Ana By 
Property (a) can be seen by inspection of C (ASC) and Algorithm 10. 
Moreover, Y also has property (b). (SL, Y)-correctness of A'S) follows 
from the (SL, V (st) )-correctness of ASL) and the fact that ¥ c Nentry X N, 
which entails 


C2 yS, 


EA {(s,t) | SL(s,t) #0} < Nentry x NO {(s,t) | SL(s,t) # 0} 
Thus, if (s,t) € Y with n € SL(s,t), then (s,t) € y's) and hence, by 
Theorem 7.18, fa < ACSH (s,t). 

A similar argument shows that (SL, VS)) precision of A(SL) implies 


(SL, ¥ )-precision of A(SL) for universally distributive frameworks. 
(ASC) 
0 

, I can state the correctness property of 


Using an appropriate choice of Y and assuming that C is definition- 


complete with respect to C (ASC) 


Theorem 7.21. 


Theorem 7.21. Let Xs; : NXN > Fa be a function and let CAS) the set of 
constraints in Constraint System 6.2 with respect to Xs;. Consider X, as input 
for Algorithm 10. 
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1. Algorithm 10 terminates and upon termination, we have 


(ASC) 
(7.38) A(s, t) = 4 (Foso) )(s, t) if (s, 2 € Vo 
K otherwise 
l , (ASC) 
2. If Xs is (SL, ¥)-correct, then A is (ASC, Vý ` ~ )-correct. 


3. If Xs, is (SL,¥)-precise and F is universally distributive, then A is 


(ASC) 
(ASC, V5 


In the following, I am going to prove Theorem 7.21. Firstly, I assume that 
item 1 is proven and consider items 2 and 3. In order to prove item 2, I 
need to generalize Theorem 6.7: Remember that Theorem 6.7 states that 
Ifp(F otasc) ) is ASC-correct if Xsz is SL-correct. But an inspection of its 


)-precise. 


proof shows that actually (SL, Y)-correctness of Xs; is sufficient for the 
ASC-correctness of Ifp(F (ASC) ). Hence, the proof of Theorem 6.7 actually 
shows the following statement: 


If Xs is (SL, Y)-correct, then 1fp(F „(asc) ) is (ASC, VAS) correct. 
With (7.38), this shows item 2. With a similar argument, item 3 can be 
shown. 


Two things are left to be done. In order to complete the proof of The- 


orem 7.21, I need to show that ee is definition-complete with respect 


to C\ASC), Moreover, I need to characterize V oe) appropriately, to be 


sure that Theorem 7.21 indeed proves Algorithm 10 correct. 

Lemma 7.22 gives a characterization of CoreVars(C (ASC) N x N) and 
yAS9) 
0 
ASC-reachability. Since C(4SC) is defined with respect to Xsr, Lemma 7.22 
has to make additional assumptions about Xs;. However, for Lemma 7.22 
to be valid, full SL-correctness or SL-precision of Xs; is not neccessary. It 
suffices to require that Xs; + m for the right points. 


. Analogously to Lemma 7.19, it provides a strong connection to 


d 
Lemma 7.22. Define dom(ASC) ‘ef { 
following statements are true: 


1. If Xs, is (SL, ¥)-domain-correct, then we have 


(s,t) € NX N|ASC(s,t) + 0}. Then the 


(7.39) dom(ASC) A Srex N c VASO) 
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Algorithm 10: Given a function Xs; : N x N —> Fa, computes the 


least ascending solution with respect to X57, 


Input: a data-flow framework instance F = (G, L, Fg, p) as de- 


scribed on page 295, a function Xs, : NX N > Fa 


Result: the least ascending solution with respect to Xs;, as stated 


in Theorem 7.21 
1 A e const(R) 
2 foreach s € Src do 
3 | Als,s) - id 
4 We WU ({(s,s)} 


5 while W #0 do 


6 (s,t’) — remove(W) 

7 foreach e € Ejntra U Erer such that t’ > t do 
8 A(s,t) — A(s,t) U feo A(s,t’) 

9 | W-WU({(s,t)} if A(s,t) has changed 


Ecall Eret 


10 foreach (eca, eret) € ® such that” > noAnı > tA 
Xsı(ng,nı) + R do 


11 sameLevellnfo — fer © Xsı.(no,n1) © fe, 
12 A(s,t) — A(s,t) UsameLevellnfo o A(s,t’) 
13 | We WU {(s,t’)} if A(s,t) has changed 


14 return A 


(7.40) dom(ASC) < CoreVars (C450), N xN) 


2. If Xsz is (SL, ¥)-domain-precise, then we have 


(7.41) VASO) c dom(ASC) N Sre x N 

(7.42) CoreVars (C450), N x N) c dom(ASC) 

3. ve and CoreVars(C (ASC), N x N) have the following connection: 
(7.43) 4 = CoreVars(C“45°),N x N) N Sre x N. 


Proof. Regarding the first two items, we only show (7.39) and (7.41), since 


(7.40) and (7.42) can be proven using very similar arguments. 
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1. Assume that Xo, is (SL, ¥)-domain-correct. Then (7.39) is implied by 
the statement 

(7.44) Yn € ASC. W(s,t) € SrcxN. n € ASC(s,t) = (st) VAS, 
We prove this statement by induction on z € ASC. The proof is largely 
similar to the corresponding part of the proof of Lemma 7.19. We only 


highlight the parts where the assumptions about Xsz are used. Hence, 


; Ecall 
we only consider the case that n = n’ -esal T” -eret With n ®© no, 


eret 


ny > t, n € ASC(s,n), n” € SL(no, nı) and (eca eret) € ®. Note that 
(no, n1) € Y. With the (SL, Y)-domain-correctness of Xsz, this means that 


ASC) 


Xs (no, nı) # &. Hence, by Asc-soL-(m), cí contains a constraint 


X(s, t) 2 Feret g X(no, nı) © fea oX(s,n). 


By induction hypothesis, we get (s,n) € V (ASC) We conclude 


0 


X(s,t) e VASO 


by (V-Base). 


2. Assume that Xs; is (SL, Y)-domain-precise. In order to show (7.42), we 
prove 


(7.45) y(s,t) e v9) 


o -ASC(s,t) #0 


by induction on (s,t) € V A) = CoreVars(C(ASC), x(45°)), So let (s,t) € 


0 
yes), Then there is c € ere with Ihs(c) = (s,t). Because the other 
cases are similar to the proof of Lemma 7.19, we only consider the case 


that c is of the form 


Xasc(s,t) = feret © XsL(no,N1) © fean ° XASC(S, 1) 
with (eall, eret) € ©, n = no, nı “3 t and Xsr(no,n1) + &. Then we have 
(no,nı) € Y. Since Xsz is (SL, Y)-domain-precise, Xs; (no, n1) # & implies 
that there is n” € SL(ng,n1). Furthermore, we may apply the induction 
hypothesis to (s,n) and get n’ € ASC(s,n). Together with the assumptions 
about e..; and eret, we get T’ + Coq: TU’ + eret € ASC(s, t), as desired. 
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3. In order to show (7.43), we consider the two subset relations separately. 


e For G, it is clear that 


Aso) < CoreVars(C (ASC) N xN), 


since Sre x N C N x N and CoreVars(C (ASC) _) is monotone. 


It remains to show 


v(s,t) e v9) 


o (8 #) € SrexN. 


The proof is a straight-forward induction along V ey where the 
induction steps work by noticing that the first components of the 
variables on the left-hand and right-hand sides of constraints in 


(ASC) 
Vo 


e For 2, induction on (s, t) € CoreVars(C\45°), N x N) shows that 


are the same. 


V(s,t) € CoreVars(C'45°),N x N). (s,t) € SrcxN 


= (Ne, 


oO 


With Lemma 7.22, I can provide the last puzzle piece to the proof of 
Theorem 7.21: The definition-completeness of Gees 


Core(C'45O),N x N). 


with respect to 


(ASC) 


Lemma 7.23. Co 


is definition-complete with respect to its superset 


Core(C'45°),N xN). 


Proof. Like in the proof of Lemma 7.20, we use Theorem 7.10. Consider 


c € Core(C\45°), N x N) with (s,t) = Ihs(c) € yee Then we have to 
show 
(7.46) FV(rhs(c)) =0 = (s,t) € x9 


(747) (s’,t’) € FV(rhs(c)) => (s’,t’) € CoreVars(C“45©, x(A50)) 
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As the other cases are very similar, we only consider the case that c € 
Core(C‘45°), N x N) is of the form 


Xasc(s,t) = fer © Xsz(o0,11) © fen ° XASC(S, n) 


with (eal eret) € ®, n ae No, nı oe Xsr(no,nı) + K, and (s,t) € 
CoreVars(C (ASC), KR ). We need to show 
(s,n) € CoreVars(C45©), Zn iE 
But note that 
s,n) € CoreVars ‚NxN), an 
1 CoreVars(C'45°),N x N), and 
(2) se Src. 


Statement (1) is implied by c € Core(C (ASC) N x N), while statement 
(ASC) 


(2) follows, by application of Lemma 7.22, from (s,t) € Vo . Both 
statements together imply (s,n) € Yin by Lemma 7.22. m) 


7.3.3 Extending the Solution Along the Non-Ascending 
Paths 


Constraint System 7.1 is a modified version of Constraint System 6.3 that 
describes the data flows along the non-ascending paths. 

The constant constraints of Constraint System 7.1 use the values X4s5c(s,c) 
with Xasc(s,c) + & to initialize the solution. Note that c can be restricted 
to N... according to Lemma 7.16. The non-constant constraints then extend 
the solution along the descending paths. 


Constraint System 7.1. Given functions Xasc,Xs, : NXN — Fa, the 
function 
XNASC :NXN > Fp 


is a non-ascending solution with respect to Xasc and Xsr if it satisfies all 
constraints from the following system: 
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E $ t eE Ecall Xasc(s,t’) #R 


Xwasc(s,t) 2 fe o Xasc(s,t’) 


(Non-Asc-(1)) 


e 
Pog e € Ejntra U E call 


Xnasc(s,t) = feo Xnasc(s,t’) 


(Non-asc-(11)) 


call eret 
n > ng n >t (€cait, Eret) c Xs (no, nı) + K 


(non-asc-(11)) —— > r n l S 
Xnasc(8,t) = feret © Xs (no, 1) © fea ° XNASC(S, n) 


Using a similar argument as in Theorem 6.7, I can prove that Constraint 
System 7.1 indeed describes NASC-correct solutions, provided that Xs; 
and X4sc enjoy their respective correctness properties. 


Theorem 7.24. Let Xs : NXN —> Fa be SL-correct, X asc : NX N > Fg be 
ASC-correct and let Xyasc be a NASC-solution with respect to Xs; and X asc- 
Then Xnasc is NASC-correct. 


Proof. Let s € N, c € Nea and nı € ASC(s,c). Using a straight-forward 
induction along m2 € DESC with arguments similar to the ones in the proof 
of, e.g., Theorem 6.6, we show 


Yn € DESC. VEEN. 
T2 € DESC(c,t) A T41 na € ASC(s, t) 
= fum < Xnasc(s,t). 


Using Definition 7.15, this shows that 


Vr e NASC. Ys,tENTE NASC(s, t) => fr < Xnasc(s, t), 


as desired. oO 


Moreover, for universally distributive frameworks and with the respective 
precision requirements satisfied for Xasc and Xs;, the least solution of 
Constraint System 7.1 coincides with MONASC. The proof is very similar 
to the proof of Theorem 6.10 and is not repeated here. 
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Algorithm 11: computes the least non-ascending solution on 


yoso 


with respect to X4sc and Xsz 


Input: a data-flow framework instance F = (G, L, Fm, p) as de- 


scribed on page 295, functions Xs, X4sc : N XN > Fg 


Result: the least non-ascending solution with respect to Xs;, as 


stated in Theorem 7.26 


1 A <— const(R) 
2 foreach (s,c) € Sre x N with Xasc(s,c) + m do 


15 


foreach e € Equ, t € N such that c £ tdo 


| Als,t) = Als,t) U fe o Xasc(s,¢) 
WeWU ({(s,t)} 


while W + 0 do 


(s,t) — remove(W) 


foreach e € Eintra U Ecay such that t £ r do 
Als, t) — A(s,t’) U feo Als, t) 
| We WUut{(s,t’)} if A(s, t) has changed 


ecall eret 


foreach (eca, eret) € ® such thtt > ngan > FA 
Xs (no, nı) + X do 

sumInfo — fet © Xs (no, 11) © fecal 

A(s,t’) — A(s,t’) UsumInfoo A(s,t) 

W e WU {(s,t’)} if A(s, t’) has changed 


return A 


Theorem 7.25. Let F be universally distributive. Furthermore, let Xs; be 
SL-precise and Xasc be ASC-precise. Then MONASC is a NASC-solution with 
respect to Xs; and X asc- 

In particular, Lfp(Fe\asc) is NASC-precise, if Cnasc is defined with respect to 
XASC and Xsr- 


Allthat remains to do is to instantiate Algorithm 8 appropriately and prove 
the usual correctness result. The instantiation can be seen in Algorithm 11. 
I fix two functions 


X asc, XSL :NXN > Fa, 
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and let C(NASC) be the set of constraints defined by Constraint System 7.1, 
with respect to Xs; and XAsc- 


I define 

(7.48) ee def {(s,c) |s € Sre Ac E€ Nean A Xasc(s,c) FR} 
(7.49) a al Core(CNASO), x(A80)y 

7.50) VNA 2f Corevars(ClNASO), x (45°) 


Like before, an inspection of Constraint System 7.1 shows that Algori- 
thm 11 is indeed an instance of Algorithm 8. Thus, assuming definition- 


completeness of C ase) in Core(C'NA4SC), N x N), I can give the following 


correctness result for Algorithm 11. 


Theorem 7.26. Let Xs},Xasc : N XN > Fa be two functions and let CnAsc 
be the instance of Constraint System 7.1 with respect to Xs; and X asc. Consider 
Xsp and Xasc as input for Algorithm 11. 


1. Algorithm 11 terminates and upon termination, we have 


(7.51) Als,t) = [i Eowsc) 9 ifs € yR 


otherwise. 


2. If Xs, is (SL, Y)-correct and X asc is (ASC, Src x N)-correct, then A is 


(Nasc, y N45) 
7 0 


3. If Fa is u.d., Xsy is (SL, Y)-precise, and Xagc is (ASC, Sre x N)-precise, 


then A is (NASC, VO 


)-correct. 


)-precise. 


In the following, I sketch a proof for Theorem 7.26. First, assume that 
the first item is shown. Then the second item follows if I can show that 
Lfp(Fouasc) ) is (NASC, V Se )-correct. But this can be concluded from 
the (SL, ¥)-correctness of Xs, and the (ASC, Src x N)-correctness of XAsc 
with a similar argument as in the proof of Constraint System 7.1. 

The third item in Theorem 7.26 can be shown similarly by adapting 
Theorem 7.25 appropriately. 
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It remains to characterize the variable y ^S c) 
a in Core(C(NASC),N x N). Lemma 7.27 gives 


a characterization of y 


and to prove the defini- 
tion-completeness of C 


that is analogous to Lemma 7.22. 


d 
Lemma 7.27. Define dom(NASC) 2 


the following statements are true: 


{(s,t) EN XN | NASC(s,t) # 0}. Then 


1. If Xs, is (SL, Y)-domain-correct and X asc is (ASC, Src x N)-domain-correct, 
then we have 


(7.52) dom(NASC) n Srex N c V\NASO) 


(7.53) dom(NASC) < CoreVars(C'N45°),N x N) 


2. If Xsz is (SL, Y)-domain-precise and X asc is (ASC, Src x N)-domain-precise, 
then we have 


(7.54) Vy'NASC) c dom(NASC) NSrcx N 
(755) CoreVars(C™450), N x N) c dom(NASC) 


3. aeae and CoreVars(C\NASC), N x N) have the following connection: 
(7.56) eed — CoreVars(C(NASO), N xN)NSrcexN. 


Proof. 1. We only consider (7.52), since the proof of (7.53) is very similar. 
Assume that Xo, is (SL, Y)-domain-correctand that X4sc is (ASC, Src x N)- 
domain-correct. Let s,c € N and 7, € ASC(s,c). Then, we can show 


Yr € DESC. Vt € N. nz € DESC(c, t) A 1 -T2 € ASC(s, t) 


= (st) e YO 


by induction on m2 € DESC. The details are very similar to the cor- 
responding part of the proof of Lemma 7.22 and are omitted here. By 
Definition 7.15, this implies (7.52). 
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2. Assume that Xs; is (SL, Y)-domain-precise and, moreover, that X,gc is 
(ASC, Src x N)-domain-precise. Then we can show 


V(s,t) e VASO., (s, #) € dom(NASC) N Sre x N 
by induction on (s,t) € V ER: For each case, the argument uses a 


combination of the respective induction hypothesis and the assumptions 
about Xs; and X,sc to obtain an appropriate non-ascending path. The 
details are very similar to Lemma 7.22 and I do not repeat them here. The 
proof of (7.54) is similar. 


3. This is completely analogous to the proof of (7.43). 
oO 


Using Lemma 7.27, the definition-completeness of C, en with respect to 


its superset Core(C(NASO),N x N) can be shown. The proof is completely 
analogous to the proofs of Lemma 7.23 and Lemma 7.20 and is omitted 
here. 


Lemma 7.28. Core(C (ASC) | Xo) is definition-complete with respect to its super- 
set Core(Cnasc, N XN). 


7.3.4 Combining the Ascending Solution and the 
Non-Ascending Solution 


Constraint System 7.2 combines two given functions X4sc and Xy asc by 
simply joining them. 


Constraint System 7.2. Given functions Xasc,Xnasc : NXN > Fa, the 
function 
Xyp :NXN > Fg 


is an alternative valid-paths-solution with respect to Xasc and Xyasc ff it 
satisfies all constraints from the following system: 


Xasc(s,t) #R : Xnasc(s,t) # B 
(vP’-(m)) 
Xyp (s,t) = Xasc(s,t) Xyp (s,t) = Xnasc(s,t) 


(vp’-(1)) 
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Constraint System 7.2 is so simple that I can give a clear and direct 
characterization of I fp(F cv) ), which is easy to see: 


(7.57) Lfp(FQqver)) = Xasc U Xnasc- 


Alternative valid-paths solutions are indeed VP-correct, if X4sc and Xpgsc 
satisfy their respective correctness conditions. This is an easy consequence 
of Remark 7.17, which is why I omit the proof. 


Theorem 7.29. Let Xasc,Xnasc : NXN > Fa be two functions. Then the 
following statements hold: 


1. Let Xyp be an alternative valid-paths solution with respect to Xasc and 
Xnasc- If Xasc is ASC-correct and Xnasc is NASC-correct, then Xyp is 
VP-correct. 


2. If Xasc is ASC-precise and Xyasc is NASC-precise, then Ifp(Fcyp,) is 
VP-precise. 


In chapter 6, we considered Constraint System 6.4 as a characterization for 
valid-paths solutions. For the following considerations, let C (VP) be the 
set of constraints from Constraint System 6.4. 

Note that Theorem 7.29 does not say anything about the relation of 
Ifp(F c(vP)) and I fp(F c(vP’)) in general, even if they are considered with 


respect to the same helper solutions. As C(Y?) and C(VP’) make different 
choices about when they join and when they compose, we cannot expect 
in general that they coincide®. In general, C (VP) and CVP’) can simply 
be seen as alternative approaches to characterize an over-approximation 
to MOVP. This is especially relevant if F is not distributive and the 
helper solutions are correct and as precise as possible (e.g. if they were 
obtained using the algorithms from the previous sections), but also if the 
helper solutions themselves are only over-approximations, even for the 
distributive case. 


36My conjecture is (a) that [fp(Foivp)) < Lfp(F give’) ) under relatively general assumptions 
and (b) that, under the same assumptions, there are examples for which Ifp(F ve’) ) £ 


Ifp(Fowvr) ), since C (VP) “joins later” than C(YPP). I will however not attempt to prove this 
within the scope of this thesis. 


317 


7 A Common Generalization of Interprocedural Data-Flow Analysis and Slicing 


For distributive frameworks and the most precise helper solutions, 
If p(Fo (vpr) ) can be shown to coincide with Ifp(F (VP) ). 


Corollary 7.30. Assume that F is universally-distributive. Consider the follow- 
ing constraint systems: 


c A459) with respect to lfp(F sr) ) 
CESS) with respect to lfp(F xst) ) 
(NASC Ei 


CP) with respect to lfp(F asc) ) and Lfp(F (DESC) ), and 


(Fes 
(Fos 

with respect to lfp( ols sı) ) and Ifp(Fo (asc) ) 
(Foa 
(Fe 


CYP) with respect to lfp(F asc) ) and Lfp(F casc) )- 


Then If p(E ov p)) = Lfp(Fo (vp’) )« 


Proof. By Theorem 6.7 and Theorem 6.10, Ifp(F ol Asc) ) is both ASC-correct 
and ASC-precise. Moreover, Theorem 7.24 and Theorem 7.25 imply 
that Ifp(F „(nasc) ) is both NASC-correct and NASC-precise. Hence, The- 
orem 7.29 implies that Ifp(F c(vP’)) is both VP-correct and VP-precise, 
ie. 

Analogously, using Theorem 6.7, Theorem 6.8, Theorem 6.10 and The- 
orem 6.9, one can conclude 


oO 


Lastly, I want to consider the connection between the domain of I fp(Fc,,p, ) 


and forward slices. Remember that the forward slice FS(s) of a given node 
s € N is the set of nodes t € N such that VP(s,t) # 0. 


Theorem 7.31. Let Xasc,Xnasc : N XN — Fa be two functions. Then the 
following statements hold: 
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1. Let Xyp be an alternative valid-paths solution with respect to Xasc and 
Xnasc- If XAsc is ASC-domain-correct and Xy sc is NASC-domain-correct, 
then Xyp is VP-domain-correct. In particular, we have 


(7.58) Ys € N. FS(s) € {t € N | Ifp(ECyp,) (5, £) # Bh. 


2. If Xasc is ASC-domain-precise and Xnasc is NASC-domain-precise, then 
Lfp(Ecyp,) is VP-domain-precise. In particular, we have 


(7.59) Ys €N. {t € N | Ifp(Fcyp )(s,t) # 8} € FS(s). 


Proof. For given s € N, we define 


FSasc(s) Z {tN | ASC(s,t) #9), and 


‚= 


FSnasc(s f {t EN | NASC(s, t) + Ø}. 


By Lemma 7.16, we have FS(s) = FSasc(s) UFSnasc(s) for all s € N. 
Moreover, by definition we have 


FSasc(s) < dom(X,sc) if X4sc is ASC-domain-correct, 
FSasc(s) 2 dom(Xasc) if X4sc is ASC-domain-precise, 
FSnasc(s) E dom(Xyasc) if XNasc is NASC-domain-correct, and 
FSnasc (s) 2 dom(Xnasc) if XnaAsc is NASC-domain-precise. 
From this, all claimed statements can be shown using (7.57). Oo 


7.3.5 Putting It All Together 


In this section, I combine the algorithms from the previous sections to yield 
algorithms that compute the least alternative valid-paths solution with the 
most precise helper solutions. 

First, I show a simple algorithm that is always correct and then I consider 
a variant that works for distributive frameworks. 

The simple approach, which can be seen in Algorithm 12, takes the set 
Src © N of source nodes as input and uses the pre-computed result ASE) 
of running Algorithm 9 on x. 
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As its first step, Algorithm 12 invokes Algorithm 10 to compute the least 
ascending-paths solution A\45°) with respect to ACSH). After that, it runs 
Algorithm 11 to obtain the least non-ascending solution A\N45©) with 
respect to ASL) and ACASO), Finally, itjoins AASC) and ANASO) to obtain 
its result AV’), 

For Algorithm 12 I can give the following simple correctness result. 


Theorem 7.32. Consider 
CP” with respect to Lfp(C'45°)) and Ifp(c'NA59) 
CASC) with respect to Lfp(c AS) and Lfp(C™), and 
Lfp(C'45°) with respect to lfp(CS")). 
Then Algorithm 12 has the following properties: 


1. Algorithm 12 always terminates and upon termination, we have 


(ASC) jy (NASC) 


(7.60) AVP) (5,1) = ENS civ) )(s,t) fteV, : 


otherwise 


d 
2. Define F = Usesre FS(s). FF is universally distributive, then 
(7.61) AVP”) =p MOVP. 


Algorithm 12: Computes the least alternative valid-paths solu- 
tion on Src x N with respect to the most precise helper functions 
Input: a data-flow framework instance F = (G, L, Fg, p) as de- 
scribed on page 295, least same-level solution ASL), node 
set Src CN 
Result: least alternative valid-paths solution, as stated in The- 
orem 7.32 
1 ASC) — ComputeAscendingSolution(Src, A'S») ) 
2 AWNASC) — ComputeNonAscendingSolution (ASE), ASO) 
3 AVP’) = AlASC) LI A DESC) 


4 return AVP”) 
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Proof. 1. (7.60) is an easy consequence of (7.57), considering the final value 
of AVP”) in Algorithm 12. 


2. Assume that F is universally distributive. Then (7.61) is an easy 
consequence of 


(7.62) Ifp(F ovr) = MOVP, and 
(7.63) y Oye = ee 
seSrc 


These two facts follow from the universal distributivity of 7, Theorem 7.29 
and Theorem 7.31. 
Oo 


7.3.6 Towards the Two-Phase Slicer 


Remember that Algorithm 6 works in two phases: The first visits all nodes 
that are ASC-reachable from the given start nodes. It uses summary edges 
to skip call edges and instead collects the call nodes on a second worklist 
W2. The second phase starts with W2 and extends the set of visited nodes 
along the descending paths of the given graph, using summary edges to 
skip return edges. 

Ican employ this pattern in my more general setting. The result is Algo- 
rithm 13, a variant of Algorithm 12 that integrates the two main steps of 
Algorithm 12 and offers large similarities to Algorithm 6. This variant also 
computes the alternative valid-paths solution on the forward slice of Src, 
provided that the given framework F is distributive. 

Like Algorithm 12, Algorithm 13 proceeds in two steps. 

The first step, which is implemented by Algorithm 14, is a variant of 
Algorithm 10 that computes the least ascending solution ACASO) with 
respect to the pre-computed least same-level solution and additionally 
collects all (s,c) € Sre X Noa such that ASC(s,c) + Ø in a set W2, which 
it also returns. It can easily be verified that Algorithm 14 has the same 
properties as Algorithm 10 but additionally has the property that, upon 
termination, Wz contains the set of all (s,c) € Src x N such that c € Negi 
and ASC(s,c) #0. 

The second step, which is implemented by Algorithm 15, then takes A(ASC) 
and W2 and executes a variant of Algorithm 11. Algorithm 15 differs from 
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Algorithm 13: Computes the least alternative valid-paths solu- 
tion on Src x N with respect to the most precise helper functions 
Input: a data-flow framework instance F = (G, L, Fm, p) as de- 
scribed on page 295, least same-level solution ASL), node 
set Src CN 
Result: least alternative valid-paths solution 
1 (ASC), Wa) — ComputeAscendingSolution’ (Src, ALSH) 
2 AVP”) — ExtendAlongNonAscSolution’ (A'S), A\ASC), Wo) 


3 return AVP”) 


Algorithm 11 in two key aspects: Firstly, it does not initialize the solution 
with const(®), but rather initializes it with A(45© and secondly, it does 
not have an initial loop. However, it also starts with a non-empty worklist 
that, by the additional correctness property of Algorithm 15, contains all 
(s,c) € Src x N such that n € Nea and ASC(s,c) + R. It can be verified that 
the initial loop is actually integrated in the main loop. 

Assuming the distributivity of 7, we can show that Algorithm 15 indeed 
computes /fp(Cyp’ ). The proof is analogous to the proof of Theorem 7.11 
and proceeds in three steps, which I state here but omit the proofs. 


1. Algorithm 15 always terminates. 


2. Algorithm 15 maintains the invariant 


{(s,t) € SrcxN | AVP) (s, £) Zac 1 gynes) 
and upon termination, we have 
{(s,t) € Srex N | AVP”) (s, t) # m} = VSO Yy4so) 


3. Algorithm 15 maintains the invariant 


BE) Ifp(F gasc) ) ULF p (Fins) ) 


and upon termination, we have 
AYP) = Ifp(Eoyascy) ULFP(Eguvasc)) = Ifp(F ovr). 
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The invariant in the last step actually uses the distributivity of F. My 
conjecture, which I will not prove within the scope of this thesis is that (a) 
Algorithm 13 always computes an over-approximation /fp(Cyp’) and that 
(b) there are non-distributive frameworks for which AVP”) > ] fp(Cvr). 


7.4 Call-String Approach 


This section is dedicated to computing a VP-correct solution using a call- 
string-based constraint system. The general pattern is the same as in the 


Algorithm 14: Implementation of ComputeAscendingSolution’ 
Input: a data-flow framework instance F = (G, L, Fm, p) as de- 
scribed on page 295, least same-level solution ASL), node 
set Src CN 
Result: Ascending solution A 
set W2 C Src x N such that (s,n) € W2 implies that n € Nq and n 
is ASC-reachable from Src 
1 A e const({R) 
2 foreach s € Src do 
3 | Als,s) - id 
4 WeWU{(s,s)} 
5 while W + Ø do 
(s,t’) — remove(W) 


7 foreach e € E;ntra U Eret such that t’ > t do 
8 A(s,t) — A(s,t) U feo A(s, t) 
9 | We Wu {(s,t)} if A(s,t) has changed 


e e 
10 foreach (e,.1],Eree) € ® such that t’ N ngan T$ EA 
call 0 1 


Xsr(no,nı) + M do 


11 sumInfo — fe, © Xs_ (no, n1) © fecal 

12 A(s,t) — A(s,t) UsumInfoo A(s, t’) 

13 Wz — W2 U{(s,t’)} 

14 W e WU {(s,t’)} if A(s, t) has changed 


15 return A 
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Algorithm 15: Implementation of ExtendAlongNonAscSolution’ 
Input: a data-flow framework instance F = (G,L,Fa,p) as 
described on page 295, least same-level solution AD, 
node set Src < N, ascending solution AAO, set W of call 
nodes that are ASC-reachable from Src 
Result: alternative valid-paths solution AVP”) 
1 AVP’) ra AlASC) 
2 while W + Ø do 
3 (s,t) — remove(W) 
4 foreach e € Ejytra U Ecay such that t £ r do 
5 | AVP) (5,8) — AVP) (5, t) LI fe o AVP”) (s, £) 


6 We WU({(s,t’)} if AVP”) (s, t’) has changed 


call eret 


7 | foreach (eere) € ® such thatt S non > PA 
Xs (no, n1) # & do 


8 sumIn fo — fer © XsL (no, n1) © fen 
f AVP) (st) — AVP) (s,t) u sumInfo o AVP) (s, t) 
W We WU {(s,t')} if AVP” (s, t’) has changed 


11 return AVP”) 


last sections. First, I am going to instantiate Algorithm 8 so that it solves 
a sufficient portion of Constraint System 6.5. After that, I will state an 
appropriate instance of Theorem 7.11. Lastly, I give a characterize the core 
variables of the subsystem solved by the algorithm and convince myself 
that the algorithm indeed solves a definition-complete subsystem. 

I fix a stack space S = (E..ı, S, <, €, push, pop, top) such that S is finite. The 
finiteness of S ensures that the complete lattice 


NXNXS yon Fr 


satisfies the ascending chain condition. 

Before I am able to instantiate Algorithm 8 to compute the least solution 
of Constraint System 6.5, I need to modify Constraint System 6.5 a bit: In 
Algorithm 8, constraints are applied by updating the left-hand sides for 
given updated right-hand sides. However, Constraint System 6.5 does 
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not present all constraints in such a form. Particularly, rer) needs to be 
transformed. 


The rere -constraints have the form 


1 re 
prO) SE leat) EL pop(Push leci 0))=0 pushen o) + e 
s X (6,60) > fons 9 Xs (6,17, push(ecan 0)) 


I fix eca] € Eca and consider the following two sets: 


A = {(0, push(€eqy,0)) | CES 
A pop(push(ecait 0)) = © 
A push(€cqy,0) + €} 
B = {(pop(o),o) |o E€ SA0 + €^ top(c) = ecan} 
The elements of A describe the relation between the two stacks appearing 


on the left-hand side and the right-hand side of a rer -rule involving 
€call, Whereas the elements of B describe this relation for a respective 
transformed rule. 

In the following, I am going to show that A = B by proving that they are 
contained in each other. 

So let (o, push(€cqy,0)) € A. Then we have 


pop(push(e.an,o)) = 0 and push (eca, 0) # €. 


Define õ a push (eca, 0). Then õ # e, top(õ) = eca and 
pop(5) = pop(push(eca,0)) = 0. 
This means that 
(o, push(ecan,0)) = (pop(6),5) € B. 
Conversely, let (pop(o),o) € B. Then o # e and top(c) = eca. Define 
ö = pop(o). Then 
push(Ccqy ©) = push(ecan,pop(0)) = 0 # € 
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and 


This means that 
(pop(o), o) z (G, push(ecatı, ö)) EA. 


The equality of A and B implies that the rer constraints from Constraint 


S 
(2) 


System 6.5 can be replaced by the following equivalent rer’ ṣẹ -constraints: 


e 
a CE t St (eert) €® o+e top(o) = eca 
Xs(s,t,pop(o)) = fer ° Xs(s,t',0) 


(2) (2) 


s in Constraint System 6.5 leads to 


The replacement of RET 
Constraint System 7.3. 


by RET’ 


Constraint System 7.3. Let S = (E.aıı, S, <, €, push, pop, top) be a stack space 
over Eg. Then Xs : NXNXS mon F is an S-solution if it satisfies the 
following constraints: 


( ) seN ( ) e€ Ejntra St 
EMPTY INTRA i—i 
a Xs(s,s,€) 2 id s Xs(s,t,0) = feo Xsl(s,t',0) 
call 
(caLL ) ecall © E call ie 
s) SS — 
Xs (8, t, push (eca, o')) 2 Fecan 9 Xs (s, E; o’) 
( (1) eret € Eret r = t 
RET 


s) Xs(s,t,e) > fer: ° Xs(s,t',€) 
e 
roji € Eret K aig t (call, Eret) ED ote top(o) = Exall 
S Xs(s,t,pop(0)) = fer ° Xs(s,t',0) 


Lemma 7.33. Constraint System 6.5 and Constraint System 7.3 are equivalent: 
X is a solution of Constraint System 6.5 if and only if it is a solution of Constraint 
System 7.3. 
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Proof. See the previous considerations. m 


Now let C'S) be the set of constraints from Constraint System 7.3 with 
respect to the abstract stack space S. Furthermore, I define 


(7.64) x) Z = {(s,s,€) | s € Src} 
(7.65) ce) = core(ctS),x)) 
(7.66) VIS) F Corevars(clS), x9) 


Algorithm 16 is an instantiation of Algorithm 8 that is supposed to solve 


CS). The initialization loop can be seen in lines 2-4 and the main loop in 
lines 5-11. The body of the main loop enumerates all constraints c with 
(s,t,0) € FV(rhs(c)) by inspecting the stack o and the outgoing edge e and 
determining which constraint to apply. 


Assuming that c% is definition-complete in Core(C (S) NxNx S), we 
get the following correctness result for Algorithm 16. 


Theorem 7.34. Algorithm 16 always terminates and upon termination, we have 


lfp (E is) (s, to) if(s,t,o) € vi 
0 


= otherwise 


(7.67) As(s,t,0) = 


Moreover, we have 
(7.68) As = vs s) Ifp(F Core(C S) NXNxS) ) = Ifp(F as) 


To fully establish the correctness and meaningfulness of Theorem 7.34, it 
remains to show that c&) is definition-complete in Core(C (S ),N xNxS) 


and give an appropriate characterization of V, ey, I start with the latter. 
The following lemma does not fully solve this task, but at least shows that 


Vv (S) is large enough?”. 


37My conjecture is that an appropriate converse can also be shown, once a suitable 
formalization of reachability on N x N x S is available. I will however not consider this within 
the scope of this thesis. 
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Algorithm 16: Algorithm for computing the least S-solution 


Input: a data-flow framework instance F = (G, L, Fg, p) as de- 
scribed on page 295, set Src C N of sources 
Result: the least S-solution, as stated in Theorem 7.34 
1 As < const(R) 
2 foreach s € Src do 
3 | As(s,s,€) - id 
4 W e {(s,s,e)} 


5 while W + Ø do 


6 (s,t,0) — remove(W) 
7 foreach e € E such that t > t do 
o if e € Eintrg Ve € Era AO = € 


push(e,o) ifee Eca 
pop(o) if o # e A (top(o),e) € ® 


v otherwise 
9 ifo’ # Y then 
10 Asls, t,o) — As(s,t',o') U feo As(s,t,0) 
11 | We WU {(s,t’,0’)} if As(s,t’,o’) has changed 


12 return As 


Lemma 7.35. For all s,t € N, we have 
APs(s,t) #0As € Src — Jo € sS. (s,t,0) € CoreVars(C s, Xo) 
Proof. We show the statement 


Yr € Pathsg. Ys,t € N. n € Pathsg(s,t) As € SreAcs(n) +Y 
=> (s,t,cs(n)) € CoreVars(C s, Xo) 


by induction on x € Pathsg. 
So let z € Pathsg be a path with n € Pathsg(s, t), s € Src and cs(m) + V. 


1. Assume that n = e. Then s = t and (s,t,e) = (s,t,cs(n)) € Xo since 
s € Src. Furthermore, C s contains a constraint 


Xs(s,s,€) 2 id 
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by emptyg. Thus, (s,t,e) € CoreVars(C s, Xo). 


2. Assume that n = n’ -e with n’ € Pathsg(s,t’) and t’ $ t. By definition 
of cs, cs(n) # R implies that cs(r’) + ©. Hence by induction hypothesis 
we may assume 


(s,t’,cs(m’)) € CoreVars(Cs, Xo). 


We observe that Cs contains the constraint 
(x) Xs(s,t,cs(n)) > feoXs(s,t,cs(n’)). 


To see this, we make a case distinction on e. 
e € Ejntra: Then cs(r) = cs(n’) and we obtain the constraint by INTRAS. 


e € Eca: Then cs(r) = push(e.an, cs(r’)) and we obtain the constraint by 
CALLS. 


e € Ere: Then one of the following statements holds: 


(1) (2) 


In case (1), we obtain the constraint by rer,” and in case (2) by RET’ ¢”. 


Since (s,t’,cs(n’)) € CoreVars(Cs, Xo), constraint (%) is contained in 
Core(Cg, Xo) and we obtain 


(s,t,cs(m’)) € CoreVars(Cg, Xo), 
as desired. 
oO 


To prove the definition-completeness, Ineed a connection between V 5) 


and CoreVars(Cs, N x N x S). Its proof is analogous to the proof of, e.g., 
(7.43) in Lemma 7.22. 


Lemma 7.36. For alls,t € N and o € S, we have 


yi) = CoreVars(Cs, NxNxS)NSrcxNxS5 
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(S) 


Now I can give the proof of the definition-completeness of Vj" in 


CoreVars(Cs,N x N x S). 


Lemma 7.37. Core(Cs, Xo) is definition-complete with respect to its superset 
Core(Cs,N xN xS). 


Proof. We use Theorem 7.10. Let c € Core(Cs, N x N x S) with Ihs(c) € 
CoreVars(C s, Xo). Then we have to show 


(7.69) FV(rhs(c)) 


=0 = Ihs(c) € Xo 
(7.70) FV(rhs(c)) + 0A x € FV(rhs(c)) 


=> x € CoreVars(Cg, Xo) 
We show the two claims separately. 


(7.69): If FV(rhs(c)) = 0, then c is of the form 


Xs(s,s,€) > id 


Since (s,s,€) = Ihs(c) € CoreVars(C s, Xo), it must be the case that (s,s,e) € 
Xo by Lemma 7.36. 


(7.70): Let FV(rhs(c)) # 0. Inspection of Constraint System 7.3 shows that 
c is of the form 


Xs(s,t,0) = feo Xs(s,t’,o’) 


where t -5 t and (s,t,0) = Ihs(c). Note that the s on the right-hand 
side is the same as on the left-hand side. Since c € Core(Cs,N x 
N x S), we have (s,t’,o’) € CoreVars(Cs,N x N x S). Moreover, since 
(s,t,0) € CoreVars(Cs, Xo), we get s € Src by Lemma 7.36. Thus 
(s,t’,o’) € CoreVars(C s, Xo) by Lemma 7.36. 


oO 


Theorem 7.34 states that Algorithm 16 solves C (S) for an appropriate subset 
of Nx N xS. In particular, for every (s,t) € Src x N such that AP(s,t) #0, 
there is some o € S such that the result As(s, t,o) = Lfp(Fovs) )(s,t,0). It 
remains to establish a connection between Ifp(F_(s)) and MOVP to be 
fully convinced that Algorithm 16 indeed yields a (VP, Src x N)-correct 
solution. 

Now define 
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A(s,t) i | |Asß, t,o). 


ces 


Then the above considerations and Theorem 6.16 entail that 


(7.71) AP(s,t) #0 — A(s,t) > MOAP(s,t). 
Moreover, if F is distributive, then by Theorem 6.18, I can refine this to 


AP(s,t) #0 = A(s,t) = MOAP(s,t) 


Finally, if S is chosen appropriately, it follows from Corollary 6.33 that 
Algorithm 16 can be used to compute a (VP, Src x N)-correct solution. 


Theorem 7.38. Assume that there is a stack abstraction between Soo and S. Let 
As be the result of Algorithm 16 and define 


A(s,t) a | |As6, t,o). 


o€S 


Then A is (VP, Src x N)-correct. 

Proof. Assume (s,t) € Srcx N. Then we have to show MOVP(s,t) < 
A(s,t). For VP(s,t) = Ø, there is nothing to show, so we may assume 
VP(s,t) # 0. Because of our assumption about S, we may apply Corol- 
lary 6.33 and yield VP(s,t) < AP(s,t) and 

(7.72) MOVP(s,t) < MOAP(s,t) 

Because VP(s,t) + 0, we get AP(s,t) + 0. Hence, we may apply (7.71) and 
get 

(7.73) MOAP(s,t) < A(s, t) 


(7.72) and (7.73) imply MOVP(s,t) < A(s, t), as desired. m) 
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Implementation and Evaluation 


In the previous chapters, I theoretically developed and examined various 
algorithms to conduct generalized interprocedural data-flow analysis on 
interprocedural graphs. The purpose of this chapter is to demonstrate that 
these theoretically stated algorithms also work in practice. To this end, I 
implemented the algorithms in the Joana framework and conducted an 
evaluation of both performance and precision. 

This chapter is organized as follows. First, I am going to give an overview 
of my implementation in section 8.1. The other sections are dedicated to 
the evaluation. 

Section 8.2 describes several aspects on the setup of my evaluation, partic- 
ularly which samples and instances I chose. Then, I describe and discuss 
the results of the performance evaluation in section 8.3. Lastly, section 8.4 
is dedicated to the precision evaluation. 


8.1 Notes on the Implementation 


My implementation allows for arbitrary data-flow framework instances. 
In order to enable evaluations and comparison with Joana’s summary 
edge computation and slicers, my implementation works on Joana’s graph 
data structure. 

In the next subsections, I am going to consider several aspects of my 
implementation in more detail. Subsection 8.1.1 is dedicated to my im- 
plementation of the functional approach and subsection 8.1.2 considers 
my implementation of the call string approach. Finally, in subsection 8.1.3, 
I will conduct a worst-case complexity analysis on all implemented al- 
gorithms. 
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8.1.1 Functional Approach 


As we still remember from previous chapters, the functional approach 
consists of a preprocessing phase that computes same-level information, 
and a two-phase algorithm that computes the actual data-flow analysis 
solution using the same-level information. In the following, I will give a 
brief overview of my implementations of both steps, in this order. 

I implemented two variants of the same-level info computations, which 
I will elaborate on in subsubsection 8.1.1.2 and subsubsection 8.1.1.3, 
respectively. Before that, in subsubsection 8.1.1.1 I give some general hints 
on how my implementations represent same-level information. 

After having described my summary info computation implementations, I 
consider my implementation of the actual two-phase data-flow analysis in 
subsubsection 8.1.1.4. 


8.1.1.1 Representing Same-Level Information 


Recall that both the summary edge algorithm and the two-phase slicer 
employ summary edges between actual-in and actual-out nodes in order to 
avoid descending into callees. 

My implementations of the generic same-level problem use a generalized 
version of summary edges: In addition to the mere information that 
there is a same-level path, my generalized summary edges in addition are 
annotated with the result of the same-level solution for the given pair of 
nodes. 

More specifically, a common difference to Algorithm 9 is that expressions of 
the form fe, o AS) (ng, n1) © fea are stored separately in a map sumIn fo. 
Moreover, my implementation of the generalized two-phase approach 
assumes that sumInfo is available. Practically, I persist sumInfo in a 
separate file using the JSON format [94]. 

I implemented two variants of Algorithm 9, consequent and optimized. I 
discuss them briefly in the following. 


8.1.1.2 Consequent Summary Info Computation 


The consequent variant is very close to Algorithm 9 and only specifies an 
order in which the worklist items are traversed. In the following, I give 
some hints on how this ordering is chosen. 
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Remember that Algorithm 9 maintains pairs (s,t) of nodes on its worklist, 
where s and t belong to the same procedure. The ordering aims to ensure 
that callees are processed before callers. The idea is that, if we process a 
given procedure p, we want to use the most recent summary information 
to avoid re-computation. Hence we aim to ensure that the procedures 
called by p are processed before p is processed. This works perfectly as 
long as there are no recursive cycles in the call graph. 

The ordering consists of two parts: The first part orders procedures on the 
call graph, while the second part orders the nodes within a procedure. 
The ordering on the call graph is obtained as follows. 


1. We are given a call graph C = (P,E) of the given PDG G where P 
consists of the procedures of the given PDG G and two nodes p and p’ are 
connected by a directed edge p — p’ if p contains a call of p’. 


2. Reverse the edges of C and obtain graph C’ = (P,E’). 


3. Compute the condensation of C’, that is, a graph C” = (S, E” ) such that 
the nodes S < 2? of C” are the strongly connected components of C’ and 
A-cr B if and only if dp € A. Ap’ € B. p >œ p’. Note that C” is acyclic 
[59, p. 98]. 


4. Now sort C” topologically. This yields a total order <top of C”. 


5. By carefully enumerating the nodes in each SCC A in a well-defined 
fashion, use <jop to obtain a function i : P > N of G’ such that i(p) + i(p’) 
iffp + p’ and i(p) < i(p’) if p and p’ belong to two different SCCs A and B 
with A <top B. 


Orderings within the procedures were obtained by enumerating the nodes 
in depth-first order. Note that this relies on Joana’s node iteration order for 
its internal PDG structure and therefore can be subject to non-determinism 
on some level. 


8.1.1.3 Optimized Summary Info Computation 


Variant optimized, which is depicted in Algorithm 17, is based on the ob- 
servation that Algorithm 9 actually computes a global same-level solution, 
although it only needs a relatively small part of it, namely the summary 
information for pairs of call nodes and their return counterparts. Instead, 
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the optimized variant only maintains the actual summary information, 
re-computes intraprocedural parts of the solution as needed and discards 
non-essential parts of them as soon as possible. Also, instead of node 
pairs that need to be updated, it maintains procedures that need to be 
re-processed on its worklist. 

Processing a procedure p means to completely re-compute the intra- 
procedural result for p and to propagate this result to p’s callers. If this 
propagation leads to a change in some summary information between 
two nodes m and n, the procedure that contains m and n is scheduled for 
re-computation by putting it on the worklist. For worklist ordering, a 
callee-caller-ordering similar to the procedure ordering of the consequent 
variant is used. 

Initially, all procedures are put on the worklist to ensure that each intrapro- 
cedural result is computed at least once. 


8.1.1.4 Generalized Two-Phase Approach 


For the two-phase approach, I implemented Algorithm 13, which can give 
precision guarantees for distributive problems. My implementation is 
relatively straight-forward. The most notable deviation from Algorithm 13 
is that the implementation uses summary information instead of same-level 
information, as described in subsubsection 8.1.1.1. 


8.1.2 Call-string Approach 


In my implementation of the call-string approach, I use a variant of Al- 
gorithm 16 that exploits fundamental properties of program dependence 
graphs with respect to their correspondence relation ®. 

Recall that Algorithm 16 uses stacks, i.e. sequences of call edges, to 
remember to which caller the analysis shall return after exiting a given 
procedure. If such a stack eca : o is given and the algorithm is about 
to leave procedure p through the return edge eret, it needs to check that 
(Ecall, Cret) € ®, i.e. that the top of the stack corresponds to eret, in order to 
proceed with tgt(e;e+) and stack o. 

In a program dependence graph, we generally have (ecall, eret) € ® if and 
only if src(e.a) and tgt(eret) belong to the same call site and tgt(egqj) and 
src(eret) belong to the same procedure. Hence, for PDGs, the stack does 
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not need to contain call edges, but only the call sites. A call site can be 
represented by the node that describes the actual call instruction. 

Hence, my implementation of Algorithm 16 uses sequences of call nodes 
as stacks. Using sequences of call nodes instead of parameter edges as 
stacks mainly saves a lot of space. This is especially beneficial for calls of 
procedures with many parameters. With the ordinary stack representation, 
all these parameters induce different, equivalent call stacks. 


Algorithm 17: A variant of Algorithm 9 that trades re- 
computation of intra-procedural results for a more compact 
solution and worklist representation — for updatelntraprocResult, 
see Algorithm 18 


Input: a data-flow framework instance F = (G, L, Fm, p) as de- 
scribed on page 295 
Result: least summary information for F 


1 procedure computeSumInfoOptimized 
2 | sumInfo <— const(®) 
3 W e Proc 
4 | while W + Ø do 
5 p — remove(W) 
6 foreach s € Entries, do 
7 newResults — updateIntraprocResult(s, sumIn fo) 
8 foreach t € Exits, do 
9 foreach (e.a1l, eret) € P and m,n s.t. m “eal ont TS 
do 
10 old — sumInfo(m,n) 
11 sumInfo(m,n) — sumInfo(m,n) U fe, © 
newResults(s,t) © fe. 
12 if sumInfo(m,n) # old then 
13 | W e WU {proc(m)} 
14 return sumInfo 
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Algorithm 18: Intraprocedural part of Algorithm 17 
Input: a data-flow framework instance F = (G, L, Fg, p) as de- 
scribed on page 295, s € N, function sumInfo: N x N — Fa 
Result: updated version of sumInfo on {s} x Exitsp 
1 procedure updatelntraprocResult(s: N, sumInfo: N X N > Fa) 


2 | Analysis — const(®) 
3 W= WUf{s} 
4 | Analysis(s,s) — id 
5 | while W + Ø do 
6 t — remove(W) 
7 foreach t’ € N such that t > t’ Ae € Eintra do 
8 old — Analysis(s, t’) 
9 Analysis(s, t’) — Analysis(s,t’) U fe o Analysis(s, t) 
10 if Analysis(s,t’) # old then 
u | We Wut} 
12 foreach t € N such that sumInfo(t,t’) #8 do 
13 old — Analysis(s, t’) 
14 Analysis(s,t’) < Analysis(s,t’) U sumInfo(t,t’) o 
Analysis(s, t) 
15 if Analysis(s,t’) # old then 
16 | wewufr) 
17 return Analysis | {s} x Exitsp 


8.1.3 Complexity Considerations 


For data-flow frameworks (L, F) where F has finite height n, an asymptotic 
upper bound on the time taken to execute Algorithm 8 can be given in terms 
of the number of applications of constraints, as this is the most elementary 
and most often executed operation in this algorithm. Any constraint on 
a given system can be applied at most n times. Hence, the total number 
of constraint applications is no more than O(|C|-n) = O(|C|-|F |). For 
frameworks where F does not have finite height but satisfies (ACC), such 
a bound cannot be given in the general case, so that the concrete instance 
has to be taken into account. 
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Next, I am going to give worst-case time bounds for the different algorithms 
I presented in chapter 7. For simplicity, I assume that F has finite height. 
Subsection 8.1.3.1 considers the algorithms of the functional approach, 
while subsubsection 8.1.3.2 consider the call-string approach. 


8.1.3.1 Functional Approach 


8.1.3.1.1 Consequent Same-Level Problem Solver In order to give a 
worst-case time bound, I give an upper bound for the size of the subset 
Co, of Constraint System 6.1 that is solved by Algorithm 9: 


ICs; 
< INentryl 
entr j 
+ $, Np E] 


peProc 


+ y. ING JEN {(n nyi non 3 t) | proc(n) = proc(t) = p}l 
peProc 

where Nee = Np N Nentry and Bu & Ep N Eintra: 

The first term counts the number of constraints of the form sL-soL-(1): 
Cor contains such a constraint for every s € Nentry. The second term 
approximates the number of constraints of the form sr-sor-(in): C,, contains 
such a constraint at most for every s € Nentry and every e € Ejntra whose 
source and target both lie in the same procedure as s. Finally, the third 
term approximates the number of constraints of the form sL-soL-(m): 
Cor contains such a constraint at most for every s € Nentry and every 
(€call, Eret) € ® such that src(e,g7) and tet (ere) lie in the same procedure as 
s. The second and third terms are only approximations since they do not 
take into account the reachability analysis performed by Algorithm 9. 


|Nentry| can be bounded by |N] and |E!"!"@| can be bounded by |E|. Moreover, 
Y X: p y 


|N {(n “call no, nı Erg t) | proc(n) = proc(t) = p}| 


can be bounded by |E|*. In summary, an asymptotic upper bound to the 
overall time needed by Algorithm 9 in terms of the size of the given PDG 
G can be given by 
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O(IFI- (IN| + INI- El + IN] - [EI?)) = O(IFI-INI-IEI). 


8.1.3.1.2 Optimized Same-Level Problem Solver For the optimized 
same-level problem solver, I give a coarse yet simple upper bound that 
only uses |N], |E], |F| and the number |P| of procedures in the given graph. 
First, consider updateIntraprocResult. It consists of an instantiation 
of Algorithm 8 that solves a part of Constraint System 6.1. Using the 
argument from above, an invocation of updateIntraprocResult takes 
no more than O(|F|- |E 2) constraint applications. Next, consider one 
iteration of the main loop in Algorithm 17: It consists of no more than |N| 
invocations of updateIntraprocResult and no more than |N|-|N| constraint 
applications. Hence, one iteration of the loop does not take more than 
O(INI -INI - IF|- IEIZ + INI- IN|) = O(INI - INI- |F| - |E?) rule applications. A 
given procedure p can be put at most |N| - |N|- |F| times onto the worklist 
(sumInfo’s domain consists of pairs of nodes and every value can change 
at most |F| times), hence the loop can be executed no more than |P| - |N 2 -|E| 
times. All in all, Algorithm 17 executes no more than O(|P|- |N |£. |F|? -|E 7) 
constraint applications. 

Again, I would like to point out that this bound is indeed very coarse and 
formally appears to be worse than the bound for the consequent same-level 
problem solver. I suspect that it is possible to conduct a more elaborate 
analysis and yield a tighter upper bound that is closer to the bound for the 
consequent variant. The evaluation will show that the optimized variant 
can perform better than the consequent variant in practice. 


8.1.3.1.3 Generalized Two-Phase Approach For Algorithm 13, similar 
considerations can be made as in paragraph 8.1.3.1.1. Hence, we arrive 
at the same rough upper bound O(|F|-|N|-|E ee However, there is one 
important aspect that needs to be highlighted. The summary information 
computation only needs to be conducted once and can then be incorporated 
into the given graph. A usual approach is to insert summary edges into the 
given graph and annotate them with the respective value of the same-level 
analysis result. Then, Algorithm 13 does not operate on the same graph as 
Algorithm 17, but on an extended graph with more edges. This lowers the 
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upper bound of 


IDN {(n feall no, nı Cret t) | proc(n) = proc(t) = p}| 


to |E| and the overall bound to O(|F|-|N|- IEI). 

To put it more shortly, using the functional approach makes the actual 
problem solver linear in the graph size, but may cause the graph’s number 
of edges to increase quadratically. Note that this also applies to simple 
slicing. 


8.1.3.2 Call-String Approach 


For the analysis of the call-string approach, I assume a fixed source 
node s € N and the stack space S; for k € IN and consider the part of 
Constraint System 6.5 where the variables have s as first component. A 
closer look then shows that there is one constraint for every edge e € E 
and every stack o € SK. This means that the size of the constraint system is 
bounded to O(|E|- |Ecarl*) = O(lEI"*}), which results in an upper bound 
of O(|F| - EIT!) for the costs of Algorithm 16. 

As I mentioned in subsection 8.1.2, my implementation uses node sequences 
instead of edge sequences to represent stacks which changes the bound to 
O(IF|-INIK*?). 


8.2 Description of the Setup 


In this section, I describe the setup of all my evaluations. Subsection 8.2.1 
describes the environment of the evaluation. After that, subsection 8.2.2 
gives an overview of the programs that I ran my analyses on. Lastly, 
subsection 8.2.3 describes the data-flow framework instances that I selected 
for this evaluation. 


8.2.1 Evaluation Environment 


The environment of my evaluation consists of the hardware and the 
software of the setup that I used but not provided myself. An overview of 
this is given in Table 8.1. 
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CPU Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz 

Memory 512 GB RAM 

Operating System Ubuntu 18.04.4 LTS 

Kernel Version 4.15.0-72-generic 

JDK openjdk version "11.0.7" 2020-04-14 

JvM OpenJDK Runtime Environment 
(11.0.7+10-post-Ubuntu-2ubuntu218.04) 


Table 8.1: Characteristics of the machine used for performance evaluations 


The machine that Iran my experiments on consisted of 80 cores. Iran 
multiple experiments in parallel, in order to save time. This may have 
slightly disturbed the results, however, I believe that this effect is negligible. 


8.2.2 Samples 


The programs I used for the evaluation are described in Table 8.2. 

As a preliminary step to all evaluations, I used Joana to construct PDGs 
without summary edges for all sample programs. I assumed a sequential 
setting, i.e. I configured Joana to not analyze threads. Moreover, I used 
context-insensitive points-to analysis, parameter modelling based on object 
graphs [78] and interprocedural exception analysis. 

Including all libraries added to the respective analysis scope, the example 
programs have between 654k and 15.7M bytecode instructions. After 
call graph construction, on average 95% were classified as unreachable. 
Additionally, Joana pruned away 53% of the remaining instructions, so 
that the parts of the programs that were covered by the resulting program 
dependence graphs had between 1.6k and 119.3k bytecode instructions. 

I divided the example programs in two groups: One group consists of four 
very large programs, namely javap, dacapo-eclipse, hsqldb and freecs, 
the other group consists of the rest of the programs. In the following, I 
refer to these programs as large, and to the others as non-large. 

The reason for this grouping is that the large programs performed substan- 
tially worse than all other programs (across all algorithms and instances), 
which is why I had to choose different evaluation parameters. 

The sizes of the corresponding PDGs are shown in Table 8.3. 
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sample name 


ant 
bibtex2website 
dacapo-antlr 


dacapo-eclipse 
dacapo-fop 
dacapo-hsqldb 
dacapo-luindex 
dacapo-lusearch 
dacapo-xalan 
eVotingMachine 


freecs 

hsqldb 
jasypt-decrypt 
jasypt-digest 


jasypt-encrypt 


javap 
jftp 
jzip 
jlex 
lethal 


maven 


mixServer 


Table 8.2: Description of the sample programs used for this evaluation 


description 


Apache Ant (version 1.9.6), as found in Ubuntu 
16.04.3 LTS 

a tool for managing the publications of the pro- 
gramming paradigms group 

sample from the Dacaro benchmark suite (ver- 
sion 2006-10-MR2) [32] 

sample from the Dacaro benchmark suite 
sample from the Dacaro benchmark suite 
sample from the Dacaro benchmark suite 
sample from the Dacaro benchmark suite 
sample from the Dacaro benchmark suite 
sample from the Dacaro benchmark suite 

a case study from the E-Voting Reference Scen- 
ario [115] 

a version of FREECS (a chat server) that was also 
used for previous evaluations [78] 

a version of HSQLDB (a database engine) that was 
also used for previous evaluations [78] 
decryption command-line tool from Jasypr[99] 
(version 1.9.2) 

command-line tool from JAsyPT for computing 
message digests 

digest command-line tool from JAsyPT 

Java disassembler from Oracle’s JDK (version 
1.7.0_80-b15) 

case study from Lovat et al. [122] 

case study from Lovat et al. [122] 

A Lexical Analyzer Generator for Java [29, 30] 
a demo program from LETHAL, a tree and hedge 
automata library developed in a student’s pro- 
ject at the University of Miinster [98] 

Apache Maven (version 3.3.9), as found in 
Ubuntu 16.04.3 LTS 

a case study from the E-Voting Reference Scen- 
ario [163] 
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name no. PDG nodes no. PDG edges 
mixServer 3865 21271 
eVotingMachine 5655 33580 
ant 7542 55397 
bibtex2website 11031 71115 
jftp 22550 170813 

jlex 33525 254996 
dacapo-hsqldb 37159 209545 
dacapo-xalan 48387 279980 
jzip 57637 349359 
dacapo-fop 87453 507111 
dacapo-luindex 140974 959292 
jasypt-decrypt 154842 1020183 
jasypt-encrypt 154868 1020173 
jasypt-digest 162970 1075326 
dacapo-lusearch 204374 1502063 
lethal 218346 3559662 
maven 238963 1795599 
dacapo-antlr 344254 2677337 
javap 827135 6907387 
dacapo-eclipse 1129723 12031685 
freecs 1497110 13494055 
hsqldb 2001268 17497510 


Table 8.3: Sizes of the PDGs in the sample considered for my evaluation 


8.2.3 Instances 


I considered the three data-flow framework instances reach (cf. subsec- 
tion 5.4.2), explicit-info-flow (cf. subsubsection 5.4.5.2) and dist (cf. 
subsection 5.4.7). Considering the reach instance enables me to compare 
the performance of my generic algorithms with Joana’s hand-optimized 
algorithms for summary edge computation and two-phase slicing. In- 
stance dist has a lattice with unbounded height. Lastly, I included 
explicit-info-flow (occasionally abbreviated by eif) as a simple ex- 
ample for language-restricted reachability (cf. subsection 5.4.5) that does 
not need additional parameters like a barrier. 
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8.3 Performance Evaluation 


In this section, I describe how I conducted my performance evaluation 
and discuss its result. 

My performance evaluation falls into two groups: Same-level problem 
solvers and data-flow analyses. I consider the former in subsection 8.3.1, 
while subsection 8.3.2 is dedicated to the latter. 


8.3.1 Same-Level Problem Solvers 


I evaluated both the consequent (cons) and the optimized (opt) variants 
of the same-level problem solver for all three considered instances. For 
comparison, I also evaluated the summary edge computation which Joana 
performs currently as part of SDG construction. As I explained earlier, this 
corresponds to the reach instance. This algorithm will be abbreviated as 
classic. A graphical overview of the runtimes for the non-large programs 
can be seen in Figure 8.1. For full results, see Table 8.5 and Table 8.6. 

The remainder of this subsection is structured as follows: In subsubsec- 
tion 8.3.1.1, I describe the method that I applied to conduct my measure- 
ment. After that, I discuss various aspects of the results: Subsection 8.3.1.2 
gives a general overview, subsubsection 8.3.1.3 describes how the graph 
size influences the runtime of the algorithms, subsubsection 8.3.1.4 com- 
pares the runtime performance of the different algorithms and subsubsec- 
tion 8.3.1.5 discusses how the instance affects the runtime. Lastly, I give a 
short summary in subsubsection 8.3.1.6. 


8.3.1.1 Method 


I ran the different algorithms m times, distributed over n JVM invocations. 
For each of the m-n runs, I performed w warm-up iterations. An overview 
of the choices of these parameters for the different samples and algorithms 
is given in Table 8.4. 

The times that I report for every sample, algorithm and instance are the 
average times of the m -n runs. 
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Figure 8.1: Runtime distributions for the various same-level problem solvers and 
instances — a-c: only non-large, d-f: including large 


8.3.1.2 General Impression of Runtimes and Error Discussion 


Generally, for all instances and most programs, all algorithms finished 
within reasonable time. For large programs, the runtimes ranged between 
several minutes (classic/reach) and up to several hours (opt). Algorithm 
cons was not able to finish its computation on the large programs within 
the given time and space constraints. 

In order to assess the quality of these averages, I also computed confidence 
intervals for confidence levels 1 — a = 0.95, assuming that the runtimes are 
normally distributed [124, §4.2]. The radii of these intervals can be found 
in the err columns of Table 8.5 and Table 8.6. With respect to this metric, it 
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chosen parameters 


example group algorithm n w heap mesut 


non-large all 10 10 3 32GB 2hours 

large reach 

large > 1 3 0 64GB 12hours 
cons 


Table 8.4: Overview of the chosen parameters for the evaluation of the different 
same-level problem solvers — m is the number of JVM invocations, n is 
the number of iterations per JVM invocation, w is the number of warmup 
iterations before each iteration 


can be said that the accuracy of the reported runtimes corresponds to the 
number of runs performed to obtain the runtimes: For large programs and 
non-classic algorithms, the error can be up to 27% relative to the reported 
time. Conversely, for the rest of the configurations, errors tend to be small 
(up to 8%, 1-2% on average). However, the benefit of performing more 
runs on large programs is negligible with respect to the effort, since the 
runtimes are an order of magnitude larger than for the non-large programs. 
Also note that the runtimes are subject to distortions caused by continuous 
optimizations and garbage collection performed by the JVM. Apart from 
trying to distribute the runs over multiple JVM invocations, I do not 
consider these issues in the scope of this thesis. For further information, 
see Georges et al. [64]. 


8.3.1.3 Relationship Between Graph Size and Runtime 


Figure 8.2 visualizes how the runtimes of the various same-level problem 
solvers relate to the graph size. Graph size is measured in the number 
of edges. We see that generally the runtime increases with the number 
of edges. The regression appears to be somewhere between linear and 
quadratic, although it is rather difficult to make a reliable statement 
here since the number of programs is too small and has some notable 
outliers. For example, all solvers consistently take longer on maven than on 
dacapo-antlr, although maven’s PDG has fewer edges than dacapo-antlr’s 
PDG (compare Table 8.3, Table 8.5 and Table 8.6). Conversely, hsqldb 
performs better relative to freecs than the ratio of their respective graph 
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sizes suggests. Still, the number of edges in a program dependence graph 
appears to be a sufficiently reliable criterion for estimating the runtime of 
the measured algorithms and does not contradict the theoretical complexity 
analysis conducted in subsection 8.1.3, which suggests that the runtimes 
of all same-level problem solvers grows no more than quadratically with 
the number of edges. 


8.3.1.4 Comparison of the Algorithms 


Figure 8.3 shows how the different algorithms perform relative to each 
other on the chosen set of programs and instances. For this, I computed for 
each pair of algorithms (a1, a2) and each sample s the ratio of the runtimes 
that a; and az took on s. Figure 8.3 shows boxplots of the resulting 
distributions. 

Two key observations can be made here. 


8.3.1.4.1 reach Instance For one, Joana’s hand-optimized summary 
edge computation algorithm is clearly superior to the two generic al- 
gorithms. It can be up to 10 times as fast as the opt variant. This 
observation is not very surprising, since the summary edge computation 
is tailored to the reach instance and was optimized especially to work on 
large PDGs. 


8.3.1.4.2 Comparison of Opt and Cons The other observation is that 
the opt variant performs moderately faster than the cons variant. Apart 
from the fact that for the majority of configurations, opt performed 2.5 
to 3 times as fast as cons, opt was able to finish the computation on the 
large samples for all instances within the given time and space constraints, 
whereas cons was not. Recall from subsection 8.1.1 that the improvement 
in opt mainly consists of a more compact worklist item representation: 
The worklist contains procedures to be processed as opposed to pairs 
of entry/exit nodes. This results in a much smaller worklist, hence less 
memory consumption. The processing of a procedure consists of a complete 
intraprocedural traversal and re-computation for all intra-procedural node 
pairs. The price of this modification is that procedures are re-processed 
even if only a small part of them changed - resulting in potentially lots 
of spurious re-computations. This is also reflected in the runtime results. 
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Figure 8.2: Relationship between graph size and runtime for the various same-level 


problem solvers and instances 
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Figure 8.3: Comparison between the evaluated algorithms for same-level compu- 
tation — a and b compare classic with opt and cons, respectively, c-e 
compare opt with cons 


The opt variant is consistently faster than the cons variant, but only by 
a moderately small constant factor. Moreover, opt is able to process 
programs with rather large PDGs, whereas cons is not. 


8.3.1.5 Comparison Between Different Instances 


Figure 8.4 compares the different instances with respect to the additional 
effort relative to the reach instance. For this purpose, I computed for each 
program the ratio between the required runtime for the respective instance 
and the reach instance. Figure 8.4 shows a boxplot of the distributions of 
these ratios. 
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Figure 8.4: Additional effort of same-level computation for non-reach instances 
(non-large programs) 


For both generic algorithms, instance explicit-info-flow takes less ad- 
ditional effort than dist. Moreover, it can be seen that algorithm opt 
performs slightly better on dist: For cons, the majority of samples take at 
least 2.5 times as much time as for reach. The corresponding factor for opt 
is less than 2. 


8.3.1.6 Summary 


The key takeaways of the runtime evaluation of the same-level problem 
solvers are: 


e all evaluated problem solvers take more time on larger PDGs - the 
runtimes appear to grow no more than quadratically with the number 
of PDG edges 


e Joana’s hand-optimized summary edge algorithm performs much 
better than the generic algorithms on the reach instance, 


e itis possible to solve the same-level problems for non-trivial data-flow 
analyses on fairly large PDGs in reasonable time, 


e more complex data-flow framework instances generally require more 
time, 
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e it is plausible that this additional work grows with the height of an 
instance’s lattice, and 


e the improved variant opt of the generic algorithm performs moder- 
ately better than the consequent variant cons- in particular, it is able 
to compute a result for fairly large PDGs, whereas cons is not. 
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eif dist 
name | cons err cons err 
mixServer | 0.08 <0.01 0.09 <0.01 
ant | 0.30 0.01; 0.41 0.01 
eVotingMachine | 0.17 0.01 0.33 0.01 
bibtex2website | 0.37 0.01 0.61 0.02 
jftp | 1.08 0.02} 1.70 0.03 
jlex | 2.21 0.03) 3.59 0.05 
dacapo-hsqldb | 3.11 0.05) 14.88 0.16 
dacapo-xalan | 4.70 0.07| 27.66 0.33 
jzip | 657 0.09) 11.79 0.14 
dacapo-fop | 10.33 0.13} 38.09 0.41 
dacapo-luindex | 39.41 0.60} 107.71 1.02 
jasypt-decrypt | 44.93 0.56] 112.53 0.78 
jasypt-encrypt | 45.91 0.64| 149.28 1.20 
jasypt-digest | 46.05 0.56| 137.91 1.06 
dacapo-lusearch | 69.56 0.78| 228.65 2.96 
lethal 1313.85 2.46| 423.53 5.76 
dacapo-antlr 385.81 3.56| 558.31 6.87 
maven [421.70 4.73|1290.46 7.60 
dacapo-eclipse 
hsqldb 
freecs 
javap 


Table 8.6: Performance results for the summary information computation, part 2 


8.3.2 Data-Flow Solvers 

I evaluated three data-flow solvers for all three instances: 
e v2p- the generic two-phase approach Algorithm 13 
e csQ—call-string approach with a depth of 0 
e cs1-—call-string approach with a depth of 1 


Note that all evaluated instances are distributive, so that Algorithm 13 
indeed produces a precise result. 
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For comparison, I also evaluated Joana’s standard two-phase slicer for the 
reach instance (v2p-classic). The full results can be found in Table 8.8 
and Table 8.9. A graphical overview is shown in Figure 8.5. 
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Figure 8.5: Overview of the runtime distributions of the evaluated data-flow 
solvers; a-c: only non-large programs, d-f: including large programs 


Next, in subsubsection 8.3.2.1, I am going to describe the method that I 
used to obtain the results. After that, I will discuss several aspects of the 
results. Subsection 8.3.2.2 gives a general impression, subsubsection 8.3.2.3 
considers the influence of the graph size on the runtimes, subsubsec- 
tion 8.3.2.4 compares the different data-flow analysis algorithms and 
subsubsection 8.3.2.5 discusses the influence of the framework instances on 
the runtimes. Finally, Isum up my observations in subsubsection 8.3.2.6. 
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8.3.2.1 Method 


In order to obtain a runtime measurement for the various data-flow solvers, 
I took for each program p a sample Sp of n nodes from p’s PDG and then 
followed the following recipe: 


e For each instance i, algorithm a and node s € Sp, run a’s instantiation 


forionp’sPDGandsm times?8 (with w warm-up iterations) ina single 
(iap,s) Caps) 


JVM fork. This results in m measured runtimes t ER E : 


e Let time(i,a,p,s)= +", ere be the average time along the m 
runs. Then let [/(i,a,p),u(i,a,p)| be an estimation interval for the q-th 
quantile of the times (time(i, a, p,s) )ses for confidence level 1 — a. 


Gap ap) shd AAP UAP) 


e Report the midpoint as the time and 


error for program p, instance i and algorithm a. 


Table 8.7 gives an overview of the parameters I chose for each configura- 
tion. For all configurations, I chose q = 0.5 (the median). To determine the 
parameters l and u, I used a statistical method for conservatively determ- 
ining estimates of confidence intervals of quantiles without assumptions 
about the underlying distribution[124, §5.2.2]. 


8.3.2.2 General Impression of the Runtimes and Error Discussion 


Generally, the measured runtimes show that the v2p solver delivers reas- 
onably fast times for all programs under evaluation, although it is clearly 
inferior to Joana’s classic slicer on the reach instance. The cs@ algorithm 
was able to finish in all configurations, while the cs1 solver did not finish 
on large program within a reasonable amount of time. 

The errors show the same pattern as in the evaluation for the same-level 
problem solvers: For most configurations, they are relatively small. For 
the large programs, where the number of nodes and runs was smaller, they 
can be very large. Hence, the times for the large programs must be read 
with caution. Keeping this in mind, I will not further discuss errors in the 
following. 


38For v2p and v2p-classic, where most times tended to be very short, I let each iteration 
run in a loop for at least 1 second and reported the average times. 
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example group algorithm chosen parameters 
nm w |] u 1-a 


v2p-classic 100 10 3 42 64 x=0.95 


non-large v2p 

cs® 
non-large cs1 10 5 3 3 8 #0.89 
l v2p-classic 100 10 3 42 64 x0.95 
arge 

v2p 
large csQ 10 5 3 3 8 #0.89 
large cs] (not evaluated) 


Table 8.7: Overview of the chosen parameters for the evaluation of the different 
data-flow solvers 


8.3.2.3 Relationship Between Graph Size and Runtime 


Figure 8.6 visualizes how the runtime of the various data-flow analysis 
algorithms relate to graph size. Graph size is measured in the number of 
edges. 

Generally, it can be seen that the runtime increases with graph size. Both for 
the classic slicer and the v2p algorithm, the runtime appears to be roughly 
linear in the graph size, whereas the call-string algorithms suggest a super- 
linear regression. We also see that there are outliers. For example, the times 
for hsqldb is consistently much lower than the times for dacapo-eclipse, 
although hsqldb is the program whose PDG has the highest number of 
edges. A reason for this may be that the evaluated algorithms not only 
solve a constraint system but also perform a reachability analysis and 
their runtime is also affected by the size of their forward slices: If hsqldb 
is less connected than dacapo-eclipse, its forward slices are smaller and 
data-flow analyses on hsqldb take less time than on dacapo-eclipse. 


8.3.2.4 Comparison of the Algorithms 


Both callstring-based algorithms perform worse than the two-phase ap- 
proach. This can be seen in Figure 8.7, which visualizes the distribution of 
the respective runtime ratios. While cs® shows roughly the same runtime 
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Figure 8.6: Relationship between graph size and runtime for the various DFA 
algorithms and instances 
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Figure 8.7: Performance comparison between the call-string-based algorithms and 
v2p 


behavior as v2p for the reach and the explicit info flow instances, it can 
however take up to twice as much time. The dist instance shows a clear 
deviation — here cs@ generally takes twice as much time and can take up 
to 3 or 4 times as much time. 

The other evaluated callstring-variant cs1 shows a much worse behavior: 
It runs 5-10 times as long as v2p and may take up to 60 times. 


8.3.2.5 Comparison Between Different Instances 


Another observation is that, like for the same-level problem solvers, 
it appears that more complex instances require more effort. This can 
be seen in Figure 8.8. It shows that the explicit-info-flow instance 
take roughly twice as much time as reach. This is consistent among all 
evaluated algorithm. The dist instance shows a more heterogeneous 
picture. Figure 8.8 shows that at least twice as much effort is required for 
dist relative to reach. However, this additional effort is much higher for 
the callstring-based approaches and appears to grow with the depth of the 
call-strings. 


8.3.2.6 Summary 


The key takeaways of the runtime evaluation of the data-flow problem 
solvers are: 
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Figure 8.8: Additional effort of DFA for complex instances relative to reach; a/b: 
only non-large programs, c/d: including large programs 
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Joana’s hand-optimized slicer performs better than the generic 
algorithms on the reach instance, 


it is possible to compute precise solutions to non-trivial interproce- 
dural data-flow analyses on fairly large PDGs in reasonable time, 


more complex data-flow framework instance generally require more 
time, 


it is plausible that this additional work grows with the height of an 
instance’s lattice, and 


the call-strings approach performs much worse than the functional 
approach and is not able to produce results in reasonable time even 
for very small stack bounds. 


361 


8 Implementation and Evaluation 


name 


mixServer 

ant 
eVotingMachine 
bibtex2website 
jftp 

jlex 
dacapo-hsqldb 
dacapo-xalan 
jzip 
dacapo-fop 
dacapo-luindex 
jasypt-decrypt 
jasypt-encrypt 
jasypt-digest 
dacapo-lusearch 
lethal 
dacapo-antlr 
maven 
dacapo-eclipse 
hsqldb 

freecs 

javap 


‚classic 
time err 


<0.01<0.01 
<0.01<0.01 
<0.01<0.01 
<0.01<0.01 
0.03<0.01 
0.04<0.01 
0.03 0.01 
0.06<0.01 
0.09<0.01 
0.13 0.01 
0.22 0.04 
0.31 0.01 
0.31 0.02 
0.33 0.01 
0.39 0.02 
0.64 0.02 
1.00 0.06 
0.91 0.06 
7.35 0.42 
12.51 0.65 
9.35 0.52 
4.30 0.32 


_ v2p 
time 

<0.01<0.01 
0.02<0.01 
<0.01<0.01 
0.02<0.01 
0.08<0.01 
0.10<0.01 
0.12 0.05 
0.25 0.03 
0.38<0.01 
0.50 0.05 
1.15 0.19 
1.72 0.03 
1.73 0.09 
1.78 0.08 
1.77 0.11 
4.19 0.14 
6.51 0.42 
6.90 0.37 
78.70 2.67 
93.57 12.04 
89.34 2.23 
33.70 2.09 


err 


. cs® 
time 
<0.01 
<0.01 
<0.01 
0.01 
0.06 
0.09 
0.10 
0.17 
0.24 
0.57 
1.15 
1.87 
1.80 
1.90 
2.49 
4.68 
10.63 2.20 
6.95 1.55 
158.14 15.23 
511.14 159.47 
281.24 39.69 
74.81 6.84 


err 


<0.01 
<0.01 
<0.01 
<0.01 
<0.01 
<0.01 
<0.01 
0.01 
<0.01 
<0.01 
0.13 
0.07 
0.06 
0.04 
0.03 
0.36 


_ csi 
time 
<0.01<0.01 
0.02<0.01 
0.01 <0.01 
0.05<0.01 
0.43 0.06 
0.54<0.01 
0.45 0.07 
0.52 0.04 
0.98 0.02 
2.37 0.09 
7.68 0.29 
8.37 0.36 
8.49 0.25 
8.50 0.31 
0.26 
2.42 
5.51 
1.06 


err 


Table 8.8: Runtime performance of the various data-flow solvers for reach 
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8.4 Precision Evaluation 


In my evaluation, I not only measured performance, but also the precision 
of the considered data-flow analyses. In particular, I practically compared 
the precision of cs® and cs1. 

It is not obvious how to measure precision of a data-flow analysis. Hence, 
in subsection 8.4.1, I am going to consider this aspect more closely and 
describe a general method that allows to practically assess the precision of 
a given data-flow analysis. In subsection 8.4.2, I will present the results of 
my precision evaluation and describe how I obtained them. After that, I 
will discuss the result in subsection 8.4.3. 


8.4.1 How to Measure the Precision of Data-Flow 
Analyses 


In program analysis theory, precision is usually a binary concept - a 
program analysis is either precise with respect to a given ideal baseline, or 
it is not. 

However, for practical purposes, it is desirable to perceive precision 
as comparative. With a comparative notion of precision, one can make 
statements like “analysis A is more precise than analysis B”. 

In chapter 6, we already encountered results that may be read as pointers 
to comparative precision statements. 

For example, in Corollary 6.33 we saw that the MOAPs, is correct with 
respect to MOAPs, if k < I. In other words, MOAPs, is always at least 
as precise as MOAPs, if k < I. Moreover, it is easy to give examples for 
which MOAPs, yields a result that is strictly more precise than the result 
for MOAPs,. 

However, it is very challenging if not impossible to theoretically and 
generally assess the precision of program analyses comparatively*”. 

It is therefore more promising to concentrate on practical evaluation that 
usually evaluates the different analyses on a concrete sample of example 
programs. 


3 According to Jansen [97], different approaches to interprocedural data-flow analyses are 
comparable, but only in simple cases. 
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One possibility to establish a comparative notion of precision is to quantify 
it using some metric that assigns an analysis a number that assesses how 
precise this analysis is. Then, the precision of multiple approaches can be 
compared using this metric. 

In chapter 4, we saw two examples for this. Firstly, in the scope of the 
SHRIFT approach we compare different points-to analyses of Joana by 
relating the number of reported information flows with the number that a 
black box approach would report that just assumes that every sink depends 
on every source. Secondly, in our work on ırsp£c, we compare the precision 
of different information flow tools by relating the number of insecure 
programs with the number of programs that were classified as insecure by 
the respective tool. 

In the following, I describe a method for practically evaluating the precision 
of a given data-flow analysis approach. The method is independent of 
instances and algorithms and only makes a few general assumptions. The 
basic idea is to compute a metric that indicates how close a given solution 
of a given data-flow analysis approach is to the respective section of the 
MOVP solution. By computing this number for a multitude of solutions, 
we get a distribution for the given analysis. Multiple analyses can then be 
compared with respect to this distribution. 

Let F = (G,L, Fx, p) be a data-flow analysis framework and let D be a 
data-flow analysis. Moreover, I fix anodes € N. Analysis D takes s as 
input and outputs a function A'S) : N > Fa. I want to compare AS) with 
the portion of MOVP where the first argument is s. Therefore, I introduce 


the function MOVP) : N > F x that is defined by 


MovP©)(t) = MOVP(s,£). 


I assume that, regardless of s, D only produces (MOVP, {s} x N)-correct 
solutions, ie. Yt € N. A(t) > MOVP(s,t). Moreover, I assume that F 
allows for practically evaluating MOVP, e.g. that it is distributive and 
allows for an effective execution of Algorithm 9 and Algorithm 13. 

A straight-forward way to assess the precision of A'S) is to evaluate the 


fraction of t for which A“) (t) coincides with MOVP®)(t). I call this metric 
the value precision and define it as follows: 
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(s) (s)(#) = (s) 
op(a) tof Ht dom Al) | AC (H) = MOVPS) (HL 
ldom (A'S) )| 


The function vp assumes values between 0 and 1 and measures the co- 
incidence between AC) and MOVP®). A value of 0 means that AC) 
does not coincide at all with MOVP (s) where as a value of 1 means that 
vp(s) perfectly coincides with MOVP(). However, one issue of vp is that 
it does not differentiate between the two main reasons for A'S) (t) and 
MOVP®)(t) to differ. For one, it may be the case that t € dom(MOVP®)) 
and Analysis‘) (t) + MOVP®)(t), i.e. that t is a node for which every 
(MOVP, {s} x N)-correct analysis must actually compute a result. The 
second case is that t € dom(Al®)) \ dom(MOVP®)), i.e. that A computes a 
value for t, although this is not absolutely necessary for a context-sensitive 
analysis (and therefore imprecise). To distinguish between these two cases, 
I introduce two additional metrics, namely the relative slice size 


=) “ef Idom(MOVP®))| 
~ ldom( A®))| 


,and 
the value precision on the common core 


peels) lit € dom(MOVP®)) | A) (t) = MOV PS) (£)}| 
een \dom(MOVP®))| l 


Both ss(s) and vpcc(s) also assume values between 0 and 1 and larger value 
reflect more precision - while ss focuses on the slice, vp.. focuses on values. 
This is reflected by the equation 


(8.1) vp(s) = ss(s) - Upec(s). 


The validity of (8.1) can be seen as follows: From t € dom (MOVP')) and 

A'S) (t) = MOVP®)(t), it follows that t € dom(A)). Hence, we can also 

write Upcc as 

lft € dom (ACAO) (t) = MOVP®) (t)}| 
ldom(MOVP®))| 


VPcc(s) = 


y 
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and from this, Equation 8.1 follows by an easy calculation. 

With help of (8.1), I can identify two important special cases. For one, 
if vpce(s) = 1, then AC) assumes perfectly context-sensitive values on 
dom(MOVP\)) but may be too large (if ss(s) < 1). Secondly, if ss(s) = 1, 
then dom(A'S)) coincides with dom(MOVP')) but may contain different 
results (if vpcc < 1). 


8.4.2 Results 


In my precision evaluation I applied the methodology described in sub- 
section 8.4.1 to obtain a practical precision comparison between the two 
call-string approaches cs@ and cs1. I considered the programs from 
Table 8.2 and the three instances reach, explicit-info-flow and dist 
that I already considered for my performance evaluation. Note that all 
instances are distributive and can be solved precisely using the functional 
approach, so that I can use the v2p algorithm to provide MOVP-solutions. 
For each of the programs and the instances, I evaluated all three metrics 
up, ss and vp.. for a sample of randomly selected nodes in the respective 
program’s PDG. For the non-large programs, I took 100 nodes, whereas 
for the large programs, I took 10 nodes. 

The distributions of the evaluated metrics are shown in Figure 8.9. 


8.4.3 Discussion 


In the following, I want to briefly discuss the results that are visualized in 
Figure 8.9. Generally, the ss distributions for cs@ and cs1 are very similar. 
In particular, with respect to the relative slice size, cs1 offers only a little 
precision gain in comparison with cs. Notably, for the reach instance, 
csd and cs1 differ only in their ss distributions. The values on the common 
core coincide completely, so that vp.. is 1 for all measurements. This is 
indeed no wonder because data-flow solutions for the reach instance can 
assume exactly one value. 

On the complex instances explicit info flowand dist, cs1 delivers more 
precise results than cs@ on the common core. I suspect that the reason for 
this is that the dist instance offers a larger space of possible values with 
more possibility for the different data-flow analyses to differ. On the other 
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Figure 8.9: Comparison of cs@ and cs1 with respect to precision; a - c: slice sizes, 
d-f: value precision on common core, g — i: overall value precision 


hand, we also see that vp.. for the dist instance offers more variability for 


cs1 than for cs®. 


Allin all, we see that, based on this sample, cs® and cs1 offer similar result 
with respect to the amount of spurious values. Regarding the computed 
values on the common core, cs1 tends to deliver a more precise value on 
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the common core, especially for complex instances. It can be imagined 
that call-string approaches with a higher bound deliver even more precise 
results. However, with regards to the performance results, the question is 
whether the precision gain is worth the additional effort. 
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Discussion and Related Work 


In this chapter, I critically discuss the approach that I developed in the last 
chapters and compare it to the existing literature. 

In section 9.2, I discuss restrictions of my approach and simplifications 
that I deliberately applied for the sake of presentation. After that, I look at 
some of the benefits of my approach and discuss possible improvements 
in section 9.3. Lastly, in section 9.4, I consider other approaches that could 
also be used to generalize slicing. 

Before I start with the actual discussion, I want to give some general 
remarks that may help to place the work in this thesis in the right context. 


9.1 The Role of Data-Flow Analysis and Slicing 
in Program Analysis 


Schmidt and Steffen [146] propose the view that a multitude of program 
analyses mainly consists of three steps: Given a program and an operational 
semantics, the program is first transformed into a model that adequately 
captures its semantics. This program model is usually some kind of labeled 
transition system - i.e. a (possibly infinite) graph whose nodes represent 
the program state and whose edges represent the possible state transitions. 
The second step consists of an abstraction that abstracts from irrelevant 
details or makes the model more tractable and still respects the semantics. 
Lastly, this abstraction of the program model is analyzed with respect to 
graph-theoretic properties. 

If all steps indeed respect the given program semantics, graph theoretic 
properties of the program model abstraction can indeed be mapped to 
actual properties of the program. 
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Following this view, both data-flow analysis and context-sensitive slicing 
are techniques that operate as third step. That is, control-flow graphs 
and program dependence graphs are abstractions of underlying program 
models. One main result of chapters 5-7 is that program dependence 
graphs and control-flow graphs can be seen as instances of the same general 
graph model. However, this generalization ignores program semantics. 
Whether or not the results that generalized data-flow analyses yield can be 
transferred to actual program properties is out of the scope of this thesis. 
For data-flow analyses on control-flow graphs, we can state that if they 
are constructed properly, they can give semantic guarantees. However, 
such a statement cannot easily be generalized to data-flow analyses on 
interprocedural graphs, let alone transferred to program dependence 
graphs. I will consider semantics more closely in subsection 9.2.4. 
Hence, within the scope of this work, generalized data-flow analysis is to 
be understood as an abstract technique for analyzing graphs with respect 
to their path sets. 


9.2 Simplification and Restrictions 


In the following, I discuss some aspects that I chose to simplify for the sake 
of presentation and uniformity. Moreover, I look at some of the restrictions 
of generalized data-flow analysis on interprocedural graphs and discuss 
possible ways to lift them. 

The first two subsections are dedicated to the simplifications and the last 
two subsections discuss the restrictions. 


9.2.1 Forward Analysis vs. Backward Analysis 


Forward analyses consider the propagation of data-flow information 
along the paths of the given directed graph, in the direction given by the 
graph’s edges. In contrast, backward analyses consider the propagation of 
data-flow information against the direction given by the graph’s edges. 

There are numerous program analyses that are naturally expressed as 
backward data-flow analyses (cf. [130, Figure 2.6]). Another important 
example of a backward analysis is slicing in its original formulation. As I 
explained in subsection 3.3.1, program slicing was originally introduced 
as a technique for focusing on the parts of a program that contribute to 
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the value of a given variable at a given program location. This naturally 
leads to the notion of backward slices. Hence, subsequent work on slicing 
mainly focused on computing backward slices. Even the summary edge 
computation was originally presented as a backward analysis [93, 137], 
although this is not strictly necessary, since the property of same-level path 
reachability is symmetric. 

Although I mainly concentrated on forward analyses, all my considerations 
apply to backward analyses as well. Adapting my framework to backward 
analyses would result in algorithms that are even closer to the original 
slicing and summary edge computation approaches. 


9.2.2 Functional Level vs. Ordinary Level and Initial 
Values 


My representation of data-flow analyses uses an ordinary lattice L of 
possible values and a lattice F that consists of monotone functions on L, 
contains the identity function and is closed under function composition. 
The goal function MOVP has values in F - ie. it assigns a pair (s,t) a 
function MOV P(s, t) that represents the transformation of data-flow facts 
along all valid paths from s to t. After MOVP has been computed or 
approximated, one can apply MOVP(s,t) to some value l € L to yield the 
transformed value MOVP(s,t) (1). 

Classically, one is not interested in the function MOVP(s,t) but rather 
the value MOVP(s,t) (init) for a specific element init € L, called initial 
information. This element is traditionally associated with the entry or exit 
node of the procedure or program to be analyzed. Hence, it is customary 
to include init into a data-flow instance and focus on the computation of 
data-flow analysis solutions that aim to approximate MOVP(s, t) (init) for 
t e N. This is also how I introduced classical intra-procedural data-flow 
analysis in subsubsection 3.2.2.1. If s is not a fixed node, then we can also 
consider init as a function N > L. 

Both the functional and the call-string approach to interprocedural data- 
flow analysis can in principle be formulated in this way: It is not hard to 
come up with variations of Constraint System 6.5, Constraint System 7.1, 
Constraint System 6.2 and the corresponding algorithms and correctness 
results that employ the initial information. The only component that 
requires the functional level is the same-level solution. The reason is that 
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we want to use MOSL (or the least same-level solution, respectively) to “fill 
the gap” between an entry node ng and an exit node n (or between a call 
node and a corresponding return node, respectively), without knowing the 
value that arrives at nọ. That is, we explicitly need a function that describes 
the transformation of data-flow facts along same-level paths from ng to nı. 
I chose to completely stay on the functional level because it is required for 
the same-level problem and I wanted my presentation to be uniform. 


9.2.3 Concurrency 


My analysis framework only considers nesting structures that occur in 
sequential programs. For both control-flow graphs and program depend- 
ence graphs, extensions have been proposed to support concurrency. In 
the following, I want to discuss these extensions briefly. 

For control-flow graphs, it has been shown that it is possible to support 
simple parallelism constructs [151] and even dynamic thread creation [117] 
and enable a limited yet important class of data-flow analyses. 

Program Dependence Graphs have also been extended to support multi- 
threading [110, 86, 65, 66]. As I briefly explained in subsection 4.2.2, 
additional edges called interference edges model data dependencies across 
thread borders. Multi-threaded PDGs can also be sliced using an iterated 
two-phase slicing approach that was first described by Nanda et al. [129] and 
later also considered by Hammer [86] and extended by Giffhorn [65]. The 
basic idea is to employ an additional loop around the two-phase slicer that 
invokes a two-phase slice each time an interference edge is encountered. 
A possible generalization of my framework to concurrent PDGs would 
be to formally characterize the paths that are traversed by the iterated 
two-phase slicer and then establish a monotone constraint system that 
characterizes the data-flow along these paths. A worklist algorithm that 
solves this system could then turn out to be a generalization of Nanda’s 
iterated two-phase slicer. 

Note that for the iterated two-phase slicer, we cannot expect that the 
iterated two-phase backward slice can be used to verify a non-interference- 
like property (or a result such as the slicing theorem, respectively). As I 
explained in subsection 4.2.1, additional dependencies have to be taken 
into account to obtain such a result. However, I think it is possible to 
re-formalize e.g. the RLSOD check, which I described in subsection 4.2.1, 
in such a way that it performs a form of slicing instead of checking, 
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possibly on an extension of the multi-threaded PDG by an additional type 
of dependency. As for the iterated two-phase slicer, one could establish 
a monotone constraint system that characterizes the data-flow along the 
paths that are traversed by the RLSOD slicer. 

In summary, I think that it is possible to extend my framework for multi- 
threaded PDGs. However, such an extension would probably be specific 
to PDGs and I suspect that the resulting data-flow analysis cannot be 
unified with data-flow analysis for multi-threaded control-flow graphs as 
described by Lammich and Miiller-Olm et al. [117]. 


9.2.4 Semantics 


Classic data-flow analyses have a strong connection to program semantics. 
Control-flow graphs can be considered as static approximations of the 
possible program executions. This connection can be used to formally 
characterize the program properties that a given data-flow analysis verifies 
[45]. 

Program Dependence Graphs can also be connected to program semantics, 
albeit not that directly: As we saw in subsection 3.4.1, PDGs have been se- 
mantically justified in the sense that equivalent programs have isomorphic 
PDGs and the reachability instance, i.e. PDG-based slicing, has been shown 
to verify non-interference. However, it is unclear how such results can be 
extended to other data-flow analyses on PDGs. 

In particular, it is not clear what a given data-flow analysis result along the 
paths of a program’s dependence graph tells about the executions of that 
program. For example, the least distances analysis from subsection 5.4.7 
provides purely graph-theoretic information about the structure of the 
given graph. 

Hence, generalized data-flow analyses on interprocedural graphs per se 
only compute properties of the given graph and additional arguments 
are necessary to provide the connection to a reference semantics such 
as program semantics. Nonetheless, I still think that such generalized 
analyses can be useful. For example, the least distances analysis from 
subsection 5.4.7 could be extended in such a way that it also constructs a 
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shortest path?" that can serve as a “simplest witness” for the connectedness 
of two nodes. Moreover, strong bridges or strong articulation points (as 
described in subsection 5.4.4) can be computed in order to automatically 
infer parts of a program dependence graph where it may be promising to 
increase analysis precision. 


9.3 Benefits and Possible Improvements of My 
Approach 


In this section, I discuss possible improvements and benefits of my ap- 
proach. 


9.3.1 Applicability of Existing Extensions and 
Improvements 


Generally, the approaches that I describe in this work are extensions of 
the two approaches presented by Sharir and Pnueli [154]. As such, they 
inherit all benefits and drawbacks. 

The functional approach yields the most precise result but only works 
effectively for a given data-flow framework instance F if the lattice of 
functions of F satisfies the ascending chain condition and functions can 
be encoded effectively. 

In the literature, we can find several contributions that improve certain 
aspects of the functional approach and that can also be applied in the 
context that I consider here. 

For example, Reps et al. [136] consider an important class of data-flow 
problems that can be encoded particularly well. For this class, which 
consists of data-flow analyses with a finite subset lattice and distributive 
transformers, it is possible to encode the summary functions in such a way 
that the whole data-flow analysis can be reduced to graph reachability. 
Sagiv et al. [145] extend this work to data-flow problems in which the 


40] suspect that such an algorithm would generally consist of two parts: (a) a two-phase 
approach that treats the edge functions and same-level information as weights and works 
analogously to a classic algorithm and (b) a second step that exploits same-level information 
to iteratively replace summary edges by shortest same-level paths. 
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data-flow facts are mappings from variables to lattice values but the 
transformers still enjoy distributivity properties. 

Moreover, one shortcoming of the functional approach of Sharir and Pnueli 
is that it does not properly support local variables. Knoop and Steffen 
[106] present a solution for this: They extend a given data-flow framework 
instance by a stack component and additional transformers for modelling 
parameter-passing. This technique works solely on the level of the data- 
flow framework instance and therefore only needs little adaption of the 
analysis approach itself. 


9.3.2 Benefits of My Framework Compared to Adhoc 
Approaches 


My theory gives a formal characterization of the results of data-flow 
analyses in terms of information transformers along certain path sets and 
provides generic algorithms to generate these results. This is beneficial in 
situations where algorithms on PDGs are considered that can be expressed 
as data-flow analyses. Having available a general result that only needs to 
be instantiated to a concrete framework instances eliminates the necessity 
of a separate correctness argument. 

One notable example is Hammer’s approach to information flow control, 
which I considered in subsection 5.4.6. While Hammer notes that his 
approach to IFC can be expressed as a data-flow analysis, he only applies 
this fact in the intraprocedural case [86, p. 103]. For the interprocedural 
case with declassification, he presents adapted versions of the well-known 
summary edge algorithm [86, Algorithm 8/9] and the two-phase slicer 
([86, Algorithm 7]) and gives dedicated correctness arguments (see [86, 
Theorem 4.10] and [86, Theorem 4.4], respectively). 

With my framework, such separate correctness arguments are not neces- 
sary: It is only necessary to show that Hammer’s approach to IFC with 
declassification can be performed by computing the MOVP solution of an 
appropriate data-flow analysis (as I did in subsection 5.4.6). Then, e.g., 
Algorithm 9 and Algorithm 12 can safely be used to compute the least 
solution, in connection with appropriate checks. 

Another example, which I want to discuss at this point, is barrier slicing. I 
already considered barrier slicing in subsection 5.4.5. 
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Krinke [111] proposes a two-phase approach with a barrier-specific pre- 
processing phase to compute context-sensitive barrier slices. The pre- 
processing phase relies on the existence of summary edges. It starts with 
the assumption that all summary edges are blocked, i.e. that all same-level 
paths contain nodes from the given barrier. Then, it iteratively unblocks all 
summary edges for which it can construct a barrier-free same-level path. 
The following two-phase approach then uses only unblocked summary 
edges and itself skips the barrier. While the correctness of Krinke’s 
approach is intuitively plausible, he does not prove formally that his 
approach indeed computes context-sensitive barrier slices. Moreover, 
Krinke’s approach is tailored to the problem of computing barrier slices. 
It is unclear how his approach needs to be adapted in order to compute 
slices with other properties. As I pointed out in subsection 5.4.5, barrier 
slicing can be viewed as an instance of a more general problem, namely the 
problem of computing all nodes that are reachable using paths of a given 
regular language. This means that barrier slices can be computed with the 
help of Algorithm 9 and Algorithm 12, which both come with formally 
proven correctness properties. Moreover, if we want to consider slices 
with other regular properties, all that we need to do is change the data- 
flow framework instance and use the algorithms for the other instance. 
However, it is worth pointing out that this flexibility comes at a price, at 
least when using the functional approach: Since summary information is 
specific to the framework instance, it can only be re-used for problems of 
the same instance. Moreover, the data-flow framework instance for barrier 
slicing is dependent on the barrier. Hence, the summary information has 
to be re-computed if the barrier changes. This problem was also noted by 
Krinke [111, p. 4]. 

There are two potential remedies to this drawback of using a generic 
approach. Firstly, one could use a call-string approach. Call-string 
approaches are also generic but do not need barrier-specific pre-processing 
phases. However, as we saw in chapter 8, they are significantly less 
precise and considerably more costly. Secondly, one could try to use a 
more elaborate data-flow framework instance. Such an instance would 
propagate the information “this path skips the following nodes” - i.e. 
node sets — instead of the binary information “this path skips the given 
barrier”. I suspect that this would result in a more expensive summary 
information computation phase, since its lattice is more complex, but 
potentially increases the re-usability for a variety of barriers. 
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9.4 Alternative Approaches to Generalize 
Slicing 


In this thesis, I consider context-sensitive slicing on program dependence 
graphs as a form of data-flow analysis on a generalized interprocedural 
graph model. However, data-flow analysis is not the only technique that 
can be unified with slicing. In the following subsections, I take a look at 
three formalisms from the literature for which I suspect that they are also 
suitable to represent program dependence graphs and context-sensitive 
slicing. 


9.4.1 Pushdown Systems 


One alternative approach is to employ pushdown systems [36, 90]. Pushdown 
systems are extensions of finite state machines that are able to represent 
the control-flow in sequential programs with recursive procedure calls. A 
configuration of a pushdown system consists of a control state and a stack. 
The control state may assume finitely many values and the stack consists 
of a (finite but arbitrarily long) list of stack symbols from a finite alphabet. 
Possible transitions of a pushdown system may alter the control state and 
manipulate the stack, depending on the stack’s top symbol. 

An interprocedural (program dependence) graph G can be represented as 
a pushdown system as follows: The possible control states are the nodes 
of G, while the stack alphabet consists of the G’s call edges. The transitions 
can then be defined in a similar fashion as the constraints from Constraint 
System 6.5. 

Pushdown systems can be analyzed with respect to their configuration 
space: For any regular set C of configurations, the set pre* (C) of configur- 
ations that reach C by a sequence of allowed transitions is also regular [36]. 
In particular, if C is given as a finite automaton, one can use a saturation 
procedure to construct a finite automaton that accepts pre* (C). This result 
can be applied to obtain a context-sensitive slicer that is more flexible than 
classical two-phase slicing. The slicing criterion does not need to be a set 
of plain nodes but can also encode regular properties about the possible 
call stacks. A simple version of such a context-restricted slicer was already 
considered by Krinke [112]. 
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The analysis of pushdown systems is not restricted to reachability. A 
pushdown system Ff can also be equipped with weights and it is possible 
to compute a form of merge-over-all-paths solution on the configuration 
transition graph of P [147]. The structure of these weights is largely similar 
to the transfer functions considered in data-flow analysis. This idea, which 
was already noted by Schwoon et al. [147], was further developed by Reps 
et al. [139], who showed that weighted pushdown systems are general 
enough to express important special cases of interprocedural data-flow 
analysis. 


9.4.2 Recursive State Machines 


Another formalism to represent PDGs, which I want to briefly mention, 
are recursive state machines [13]. Recursive state machines are a model 
of sequential, imperative, recursive programs and consist of multiple 
components, which may have multiple entries and exits. Slicing then can 
be expressed as reachability analysis on recursive state machines. Such an 
analysis can be performed using a functional approach [13]. 


9.4.3 Visibly Push-Down Languages 


The valid paths considered in this thesis appear to be an example of 
visibly push-down languages [15, 14]. Their key feature is that they are 
recognized by a class of push-down automata that are restricted in their 
stack manipulation operations. This restriction is still general enough to be 
useful in program analysis — yet, visibly push-down languages enjoy nice 
closure properties. For example, they are closed under intersection (unlike 
general context-free languages) and union (unlike deterministic context- 
free languages). Hence, by employing visibly push-down languages, 
one could define and compute language-restricted slices with respect 
to properties that are expressible by visibly push-down languages — 
a generalization of the regular language-restricted slices considered in 
subsection 5.4.5. 
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Conclusion 


10.1 Summary and Main Theses 


In the following, I give a summary of this dissertation and revisit the main 
theses stated in section 1.3. 


10.1.1 Applications to Software Security 


Summary Chapter 3 gave a general overview of static analysis tech- 
niques and data structures, including data-flow analysis on control-flow 
graphs and slicing on program dependence graphs. It also mentioned the 
connection between slicing and information flow control. The last section 
of chapter 3 described the PDG-based information flow control tool Joana 
and several analysis techniques for object-oriented languages such as Java. 
Subsequently, in chapter 4 I reported on the contributions of the program- 
ming paradigms group at KIT to the priority program RS°. 

I presented research results of the sub-project “Information Flow Control for 
Mobile Components” concerning information flow control for concurrent 
languages. In particular, I described a static PDG-based check to guarantee 
probabilistic non-interference that was developed in our group within the 
scope of RS?. 

Ialso reported on the contributions of our group to two of the three reference 
scenarios of RS°, namely “Security In E-Voting” and “Software Security 
For Mobile Devices”. In the former, Joana is combined with a theorem 
prover to verify cryptographic properties of prototypical electronic voting 
systems, and in the latter, Joana provides static checks of user-defined 
security policies in the server component of a secure app store. 
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Lastly, I described several collaborations within RS?. In these collabor- 
ations, we demonstrate that Joana can be used to increase the precision 
and performance of dynamic usage control and to simplify the security 
verification obligations in component-based systems. A third cooperation 
is concerned with the development of RIFL, a machine-readable language 
dedicated to the specification of security properties. RIFL specifications 
can not only be read by machines, but also be checked by information flow 
analysis tools. I contributed a Joana-back-end for RIFL. An application of 
RIFL is ırspec, a benchmark for information flow analysis tools. 


Main Thesis 1: PDG-based information flow control is useful, prac- 
tically applicable and relevant. As shown in chapter 4, applications 
of Joana range from highly relevant scenarios such as mobile security 
and electronic voting systems to the support of both theorem provers and 
dynamic usage control systems. 


10.1.2 Systematic Approaches to Advanced Information 
Flow Analysis 


Summary In chapter 5, I developed a general notion of valid paths and 
described a graph-based model and a data-flow framework that incorpor- 
ates both interprocedural data-flow analysis on control-flow graphs and 
PDG-based slicing as special cases. I discussed several examples from the 
literature that can be expressed systematically within this framework. 
Chapter 6 demonstrated that instances of the general framework developed 
in chapter 5 can indeed be solved with the two classical approaches of Sharir 
and Pnueli [154] - the functional approach and the call-string approach, 
respectively. I specified monotone constraint systems whose least solutions 
can be used to compute an over-approximation of the merge-over-all-valid- 
paths (MOVP) solution given by the framework instance. Similar to 
classic results, I showed that the functional approach and the unrestricted 
call-string approach both fully characterize the MOVP solution. For the 
call-string approach, I gave a sufficient criterion under which it yields a 
correct over-approximation of MOVP using a possibly finite constraint 
system. I showed that this criterion is in particular satisfied for call-strings 
whose length is at most k. 
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In chapter 7, I showed how the constraint systems developed in chapter 6 
can be solved algorithmically. Here, I combined a classical worklist-based 
solving algorithm with a reachability analysis that explores the relevant 
core of the given constraint system. Given a set of variables to start with, 
only the constraints that the initial variables may influence are solved, 
provided that the initial variables satisfy a regularity condition. Roughly 
speaking, this can be imagined as computing a (forward) slice of the given 
constraint system. I instantiated the resulting algorithm multiple times to 
obtain solving algorithms for the constraint systems of the functional and 
the call-string approach. Using this method, I showed that the functional 
approach can be performed analogously to the methods proposed by 
Horwitz et al. [93, 137] for context-sensitive slicing: First, the same-level 
problem needs to be solved. This can be understood as a generalization of 
the summary edge computation. After that, a two-phase algorithm can 
be used to solve the actual problem. I also showed that the call-string 
approach can be performed using an appropriate instance of the general 
algorithm. 

Within the scope of this thesis, I not only developed a general framework 
and its solution approaches theoretically, but also implemented it in Joana 
and evaluated it to demonstrate that it is practically feasible. In chapter 8, I 
presented my implementation and discussed some of the practical choices 
I made. In addition, I discussed the methods and results of my evaluation. 
Last but not least, in chapter 9 I discussed my approach and put it into 
the context of related and similar work. I pointed out the restrictions 
and possible improvements and extensions. Moreover, I discussed other 
formalisms that also appear to be a natural generalization of context- 
sensitive slicing. 


Main Thesis 2: Data-flow analysis can be systematically applied to 
program dependence graphs. The theory that I developed in chapters 
5-7 proposes to view context-sensitive slicing as a special case of a gen- 
eralized version of the classical technique of interprocedural data-flow 
analysis. Particularly, this applies to earlier PDG-based approaches such 
as Hammer’s IFC [86, 87] and Krinke’s barrier slicing [111, 110]. 

Hence, PDG-based approaches can profit from the advantages of a rich, 
generic toolkit for systematically deriving sophisticated analyses: If a given 
problem on a PDG can be expressed as a data-flow analysis instance, the 
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framework provides generic and re-usable solution algorithms with general 
correctness guarantees that give formal descriptions of the solutions. This 
also includes correctness arguments such as the ones given by Hammer 
and Krinke for their respective problems. 

Moreover, I demonstrated that generalized data-flow problems can be 
described with both a functional approach and a call-string approach. The 
resulting constraint systems can then be solved with a general solution 
algorithm that integrates a classical worklist algorithm with a reachability 
analysis. The instantiations of this algorithm for the functional approach 
can be modified in a way such that they resemble a generalization of 
the summary edge computation and the two-phase approach known for 
context-sensitive slicing [93, 137], respectively. 


Main Thesis 3: Data-flow analysis on PDGs can be practically con- 
ducted. My evaluation demonstrates that it is also practically feasible 
to solve complex data-flow analysis problems on program dependence 
graphs. Moreover, it shows that the functional approach outperforms 
the call-string approach with respect to both performance and precision. 
A side product of the precision evaluation is the formal description of 
an instance- and approach-independent method for the precision evalu- 
ation of data-flow analyses. Future work can use this method to ensure 
comparability. 


10.2 Future Work 


I want to close this thesis by giving an outlook on future work. I restrict this 
outlook to the area of generalized data-flow analysis on interprocedural 
graphs like program dependence graphs, to which I consider this thesis as 
a starting point. 


10.2.1 Approximation of Same-Level Information 


One characteristic of the functional approach is that the two-phase al- 
gorithm that solves the actual constraint system relies on a same-level 
solution. The most precise same-level solution can be computed by an 
algorithm like Algorithm 9 or Algorithm 17. The evaluation in chapter 8 
shows that this can be quite expensive. However, my theory provides a 
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remedy for the case that precision can be sacrificed. In fact, the correctness 
properties in section 7.3 state that the algorithms for computing ascending 
and non-ascending-path solutions still produce correct results if they are 
fed with a same-level solution that is not as precise as possible. This 
opens up a possibility for less precise yet faster ways to produce correct 
same-level solutions. 

An extreme example would be to simply use a same-level solution whose 
value is always the greatest element T. This is surely SL-correct because of 
the maximality property of T. More generally, we could exploit domain- 
specific knowledge about the data-flow framework instance and use a 
value for which we know that it is a universal upper bound of MOSL. For 
example, consider the dist instance that was described in subsection 5.4.7 
and evaluated in chapter 8: According to its definition we have T = 0. 
Using sucha simplified same-level information would amount to a distance 
calculation that would assume that entries and exits of the same procedure 
are connected by a path with length 0. Such a distance calculation would 
result in statements like “nodes s and t are connected by a valid path that 
has a length of at least n”, which are still correct if the length of same-level 
paths is coarsely underestimated*!. 

Other approximations of same-level information are imaginable. One 
variant, which I considered more closely within the scope of this thesis but 
did not evaluate practically, uses a IN-indexed family of constraint systems 
Cy, so that for all n € IN we have 


(a) Lfp(Cn) > MOSL 
(b) Ifp(Cn+1) <Ifp(Cn) 


Property (a) ensures that we can correctly use any lfp(C„) as same-level 
information, while property (b) entails that we can get more precision by 
just increasing n. A special case of this scheme uses constraint systems 
Cn that are defined in a similar fashion as Constraint System 6.1, but 
have a different s_-sox-(111)-clause: Instead of recursively relying on the 
solution characterized by the constraint system itself, it consults l fp(Cx) 


41 As] already briefly mentioned in subsection 5.4.7, Krinke [110] also considered distances 
in system dependence graphs and since he does not provide details about how he computed 
distances of same-level paths, I firmly suspect that he assigned summary edges a value of 1 
(like any other edge), which also is a very coarse underestimation. 
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for some k < n as a helper solution for same-level information”. Property 
(a) ensures that this indeed characterizes a solution that is correct with 
respect to MOSL. Every lfp(Cn) can then be computed by subsequently 
computing /fp(Co),...,lfp(Cy_1) and then, finally, computing | fp(Cn). 


10.2.2 Further Exploration of Stack Spaces and 
MOVP-Correct Abstractions 


In chapter 6, I introduced stack spaces as an abstract structure for rep- 
resenting call stacks. The constraint system for the call-string approach 
is parameterized with a given stack space. This enables me to not only 
consider one call-string approach but multiple concrete instances that 
differ only in the stack space parameter. I also provide stack abstractions 
as a tool to relate two stack spaces. With the help of stack abstractions, I 
state a sufficient criterion for when the call-string approach with respect 
to a given stack space leads to a MOVP-correct solution. This criterion 
requires that there has to be a stack abstraction from the stack space Sœ% of 
unbounded stacks to the given stack space. Examples for the satisfiability 
of this criterion, and hence for stack spaces that lead to MOVP-correct 
solutions, are the k-bounded stack spaces Sx. 

There are two open questions in this context: 


1. Is the criterion necessary for obtaining a MOV P-correct solution? 


2. Are there, apart from the S;, other stack spaces that lead to MOVP- 
correct solutions? 


If these two questions can be answered, we could either be assured that 
there are no other stack spaces that lead to MOVP-correct solutions, or other 
appropriate stack spaces could be found that offer a better compromise 
between precision and performance. 

Regarding the first question, stack abstractions as introduced in this work 
have the restriction that they do not change the alphabet. It may be 
sensible to explore whether and how this restriction can be lifted. If it is 


“This idea can indeed be used to construct such a family (Cy )nen of constraint systems 
from Constraint System 6.1 as follows: Cp demands X(s,t) > T for all s,t € N, and each C, 
is a copy of Constraint System 6.1 where the s-sox-(111)-clause is modified such that the 
right-hand side relies on I fp(C,,-1) as a helper solution for same-level information. 
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possible to obtain stack spaces with MOVP-correct solutions from Soo via 
such generalized stack abstractions, then it may also be possible to obtain 
MOVP-correct stack spaces for which there is no ordinary stack abstraction, 
so that the first question would have to be answered negatively. 

I suspect that the answer to the second question is that there are indeed 
stack spaces other than S% that satisfy the criterion. It seems possible that 
there are stack abstractions that do not apply the same bound to all stacks 
but crop each stack depending on their content. More formally, given a 
function d : E* — N, one can define 


a(o) = o<4(0) 


y(o) =a, 


which should be a stack abstraction. Note that d has to be bounded so that 
the resulting constraint system is finite. 


10.2.3 Relation Between the Results of Data-Flow 
Analysis on PDGs and Program Semantics 


An important special case of my general data-flow framework is data-flow 
analysis on PDGs. Allthe examples that are described in this thesis are 
inherently graph-theoretic, i.e. they do not allow for conclusions about 
semantic properties of the program represented by the PDG. From my 
point of view, this gap needs to be examined further. Some interesting 
questions in this area include: 


e To what extent can data-flow analyses on PDGs be generated sys- 
tematically from a given program’s semantics (as discussed in sub- 
section 9.2.4)? 


e What kind of properties can be examined or verified this way? To 
what extent can a connection between the valid paths in a PDG and 
the set of program executions be established? 


Or, respectively, do we need some other kind of program semantics 
artifact that can serve as basis for a set of valid PDG paths? 


e How does data-flow analysis on PDGs have to be adapted to make 
such a connection possible? 
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10.2.4 Generalization of Chopping 


Chopping [96] was introduced as a generalization of slicing to enable 
the extraction of more focused program parts. A chop has two nodes s 
and f as parameter and is defined as the set of nodes that lie on valid 
paths between s and t. Like for slicing, approaches for the computation of 
context-sensitive chops have been proposed [138]. 

I think that it is possible to generalize chopping in a way that is similar to 
how slicing was generalized in this thesis. The objective function of such 
a generalization would take not two arguments, like MOVP, but three 
arguments s, t and n. Its value MOVP.„(s,t,n) could be defined as the 
merge-over-all-valid paths from s to t that also contain n. Analogously 
to MOVP, one could try to approximate MOVP.„ by means of monotone 
constraint systems. I suspect that this can be done both with a functional 
and a call-string approach. A benefit of such an analysis would be 
significantly more detailed results, and hence more information than for 
the slicing variant. For example, for the dist instance, one could yield 
statements like “all paths from s to t that pass n have a length of at least k” 
- that is, with the additional argument, one would get a whole spectrum 
of results instead of just one. 


10.2.5 Extensions to Concurrent Programs 


As already discussed in chapter 9, the framework that I develop in this 
thesis is restricted to sequential constructs. Hence, future work should 
explore how this restriction can be lifted. Possible ideas for PDGs, which I 
considered more closely in subsection 9.2.3, include (a) formalizing and 
generalizing slicers for concurrent PDGs, like for example the iterated 
two-phase slicer, and (b) examining and generalizing the constraint system 
that are solved by IFC checkers on multi-threaded PDGs such as the RLSOD 
approach [31]. 


10.2.6 Exploration of Other Generalizations of 
Context-Sensitive Slicing 


As already pointed out in subsection 9.4.1, other formalisms than data- 
flow analysis could be considered as possible generalizations of context- 
sensitive slicing. For example, Push-Down Systems enable slicers that 
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10.2 Future Work 


allow for significantly more flexible queries. Such an approach could 
also be generalized to an analysis that not only computes a slice, but also 
computes data-flow analysis results (or weights, respectively). 
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Proofs 


A.1 Proof of Theorem 5.9 


Lemma A.1. Let n € Bal(E) be a balanced symbol sequence. Assume that 
(i, j) € vn and that either of the following holds: 


(i) iis the least call position. 
(ii) j is the greatest return position. 
Then both n“ and re”) are balanced. 


Proof. We first consider case (i). Since n is balanced, we have e(n<?) >0 
for any i’ < i. Furthermore, c(7<') must be 0 because 7“! contains no call 
symbols. This together proves that rn“ is balanced. Now we show that 
n?Í is balanced. It suffices to show that (1) c(n”/) = 0 and (2) c(n}/*l) > 0 
for every k €]j,n—1], where n = Ir. 

We have c(7) = 0 since 7 is balanced. Moreover, we already have argued 
that cn“) = 0. Furthermore, because (i, j) € vz, mil is balanced, so we 
have c(r!#il) = 0. Together we can conclude: 


0=c(n) = ce(n“}) +e(n7/ 


(17!) 
= c(n~) + cr’) + (all) + efri) + e(t) 


=0+1+0+(-1)+c(n”) 
=0+c(n”) 
= c¢(n7!) 
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It remains to show that c(n!/*l) > 0 for every k €]j,n — 1]. For this, note 
that 
(nT) = c(n“) +¢(n') + cn) =04+14+0=1 


and c(n/) = -1. 
Now pick any k e]j,n- 1]. Then we have 


0 <c(n*) 

=c(n</) + cr) + ¢(nli*l) 

=1+(-1) + c(n*l) 

= c(nlikl). 
Now consider case (ii). We have c(0) > 0 for every prefix 6 of nr“! since 
mis balanced and c(6’) > 0 for every prefix 0’ of m7/, since n?! does not 
contain any return symbols. Furthermore, due to the balancedness of "I 
we can derive 

0 = e(m) = e(n“‘) + e(r) + e(r) + e(r) + en”) 
= c(n) +1 +0 + (-1) +¢(n7/) 


= e(n*!) + e(n”) 


Since both c(n“) and c(n”/) are not negative, they must both be 0. In 
summary, we have shown that both c(*') andc(m7/) mustbe balanced. o 


Theorem 5.9. For any symbol sequence n € E*, the following conditions are 
equivalent: 


(a) nis balanced. 

(b) vr is left- and right-total, i.e. a bijective function Callpos(m) — Retpos(r). 
Proof. (a) = (b) 

We show that the claim 


Yr € E*. n balanced — vz bijective 
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A.1 Proof of Theorem 5.9 


by strong induction on the number K € N of call symbols in n. 


induction hypothesis: The claim is proven for all 7’ which contain L < K 
call symbols. 

Let m € E* be a symbol sequence with K call symbols and assume that 7 
is balanced. Then, by Lemma 5.4, 7 also contains K return symbols. Let 
n = |n| be the length of n. 

If K = 0, i.e. if n does not contain any call or return symbols, then vz is the 
empty relation and therefore trivially fulfills the conditions of a bijective 
function between empty sets. 

Now assume that 7 contains K > 0 call and K return symbols. We show 
left- and right-totality separately. 

left-totality Let i € range(n) be the least index such that T; = eca € Ecall- 
Hence, we can write 


(A.1) n= ney n 


First, we show that there must be a k e]i,n| such that c(rdikl) <0. This can 
be seen as follows. First, due to the choice of i, n“ does not contain any call 
symbols. Moreover, because rt is balanced, we have c(n“') > 0. But this 
means that nr“ cannot contain return symbols either. Hence, c(m“!) = 0 
and from this, we derive that c(m”!) < 0 by the following computation: 


0 =c(z) { 7 balanced } 
= c(n*") + clec) + e(r’) { (A.1), additivity of c } 
= c(7;) + e(n”‘) te(n“ )=0} 
> e(n’). {r € Ecan } 


But by definition of c, c(r”!) < 0 implies that there must be k €]i,n[ such 
that c(nl'kl) < 0. 


Now let j be the smallest k e]i,n| such that c(n!'*) < 0. Obviously, we 
have i < j. Moreover: 


enje Eye: If this were not the case, it would follow that 
(nl) <0 


a contradiction to the choice of j. 
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e Fork’ eli, j|, consider the prefix rn] of alil, Then c(i’) > 0, since 
K’ < j and j was chosen to be the smallest k with c(n!'*) < 0. 


e c(nl"il) = 0: From the previous fact we know already that c(n"il) > 0. 
Furthermore, because 0 > e(n) = c(nlil) + e(n;) = e(nléil) + 
(-1), we can also conclude that c(m#il) < 0. 

From the former two statements we conclude that rn’! is balanced. Now 
we have 7 l 

m= meray nH ee n 
and have shown that rı"il is balanced. Together with i < j and n j = ret € 
Eyer this entails (i, j) € vz. 
Now, because 7 is balanced (by assumption) and due to the choice of i 
we can apply Lemma A.1 and additionally conclude that nr” is balanced. 
Since both nl’! and nr”) contain at most K — 1 call symbols, we can apply 


the induction hypothesis to them and gain that vl and v „>j are bijective, 
so in particular left-total. 


Let i’ + i be another call position of 7. Due to the choice of i, it must be 
i >iand since 7; € Ere, we conclude that either i’ < j ori’ > j. fi <j 
then by using that n” = (nl#/l)"-(| and the left-totality of vlij We 
obtain a j’ such that (i’ - (i + 1), j’) € v iji which means by Lemma 5.17 
that (i, j’ + (i+1)) € vr. Similarly, we find a j’ with (7’, j’) € vn in the case 
that i’ > j. This concludes the proof of the left-totality of vr. 


right-totality Let j € range(rt) be the greatest index such that nÍ € Eyer. 
Then we have 


0 > cn) = cn) +e(n/) = cn“) -1, 


which means that c(77</) > 0. Hence, by the properties of c, there must be a 
k € (0, j[ such that c(7!*/l) > 0. We choose i to be the greatest such k. Then 
we have i < j. Moreover, due to the maximality of i, we have c(nlbi l) <0. 
Lastly, we have 


0< e(n bil) = c(r') + (nl). 


Because c(r#il) < 0, this necessarily entails e(r’) > 0, i.e. c(r) = 1, and 
e(rlidl) =: 
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A.1 Proof of Theorem 5.9 


Now let k €]i, j[. Then we have 
0 = e(r til) = efri) + cent), 
but since k > i and because of the maximality property of i, it must be 


c(r!%il) < 0, which means that c(n'#) > 0. 


Together this shows (i, j) € vz. By Lemma A.1 and the choice of j, 7“! is 
balanced. For the other return positions j’ < j we proceed similarly to 
the left-totality part: We apply the induction hypothesis (noting that nl 
and 7“! contain less call symbols) and Lemma 5.17 to obtain i’ such that 
(i, 7’) vn. 


(b) — (a) Let x € E* be a symbol sequence such that 
Vry : Callpos(m) > Retpos(r) 


is a bijective function. We must show that r is balanced. By Lemma 5.6 it 
suffices to show that 

(1) c(m) =0 

(2) Vi € range(m). c(n“') > 0 

Claim (1) is clear because of the bijectivity of vz and the first statement in 
Lemma 5.4. 


It remains to show (2). We proceed by strong induction on i. Let i € 
range(rt). The induction hypothesis is 


(IH) vr <i.c(n“”) >0 


We have to show c(n“') > 0. For this, we make a case distinction on 
whether i = 0 or not. 


e Ifi = 0, the claim follows easily from the definition of c. 


e Now assume i # 0 and consider nm. For ni € Eintra U Eca, we have 
c(m') > 0. Moreover, by (IH), we have c(n“'-1) > 0. These two facts 
entail e(n) = c(n“)+c(r!) = 0. 
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Now consider the case that 7; € Eye. Since vz is bijective, there is 
j <isuch that n; € Ecay and rll is balanced. We conclude 


en“) = cn) +e) + ell) > 0. 
—~~_ ea —- aia i 
>0 by (IH) =1 =0 


This proves that c(7=") > 0. 


A.2 Proof of Theorem 5.10 


Theorem 5.10. Given n € E*, assume that (i, j), (i’, j’) € vn. Then one of the 
following statements is true: 


2. {i yle bj 

3. [i Init.) =0 
Proof. For (i,j) = (i, j’), the theorem is trivially true. If (i,j) # (i,/’), 
then left- and right-uniqueness of vy (Theorem 5.8) gives us i # i’ Aj # j. 


Also note that i + j’ and j #1’, because ré, n” € Egy and ni, n € Ere. 
Since (i, j) € vz, T can be split up into 


T = nm j Tř : qliil d rm f ns, 


where 7; € Ecaj, Tj € Eyer and mil is balanced. Now, we make a case 
distinction of where 7’ lies relative to i and j and show for every case that 
one of the three conditions from the claim must be true. 


i’ <i : Then j’ cannot be in ji, j|. Assume, for the purpose of contradiction, 
that it were. Since Wil is balanced, we may apply Theorem 5.9 and find 
i” such that (i”, j’ - (i+1)) € v jij By shifting, we see that (i” + i+ 
1,j’) € vn. Since vz is left-unique, this means that i’ = i” +i+1. But, 
since i+1 > 0, it must be i’ > i, which contradicts the case we consider 
currently. So, the assumption that j’ is in |i, j| is false. It follows that either 
j <ior j’ >j. In the former case, since j’ > 7’, we have [i, j| N t, j’] = 0 
and in the latter case we have (i, j] < [i’, j’]. 
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A.3 Proof of Theorem 5.19 


i’ >iAi’ <j : First, we note that j’ > i. This follows from (i, j’) € vn and 
i’ > i. Moreover, we observe that j’ cannot be greater than j. This can be 
shown analogously to the previous case, by shifting around, by using that 
Vr is right-unique and by exploiting the balancedness of nisl In summary, 
we have shown (i’, j’| < [i j]. 


Since (i’, j’) € vr implies i’ < j’, it must also be j’ > j. So we have 


>j: 
an, j|=0. 


A.3 Proof of Theorem 5.19 


Lemma A.2. We have Ejntra < Bal(E), Ecay < Right(E) and Eret © Le ft(E). 


Proof. e Fore € Ejytra, Ve is both left- and right-total, since Callpos(e) = 
Retpos(e) = Ø. This implies e € Bal(E) by Theorem 5.9. 


e For e € Eca, Ve is right-total, since Retpos(e) = 0. 


e Fore € Eret, ve is left-total, since Callpos(e) = 0. 
oO 


Lemma A.3. Le ft(E), Right(E) and Bal(E) are all closed under concatenation. 
1. If m,n’ € Left(E), then n:n € Left(E). 

2. If n,m’ € Right(E), then nn’ € Right(E). 

3. fr, n € Bal(E), then n:n’ € Bal(E). 


Proof. 1. Leti € range(n : n’). Then either i € range(rn) ori = |n| + i’ with 
i’ € range(r’). We consider each case separately: 

a) If i € range(n), then because n € Left(E), there is j € range(m) < 
range(m- 7’) with (i, j) € vz. 

b) Ifi = |x| +7’ with?’ € range(n’), then because n’ € Left(E), we find 
j € range(n’) with (i, j’) € vw. Then (t + In], 7’ + Il) = (ij + Irl) € 
Van’ by Lemma 5.17. 


2. This follows by an analogous argument as the first statement. 
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3. This is a consequence of Theorem 5.9 and the first two statements. 
oO 


Lemma A.4. If n € Bal(E), eca € Ecay and eret € Eret, then eca ` Ti: eret € 
Bal (E). 

A j def 
Proof. Let n € Bal(E), eca € Eca and eret € Eret and define n’ = eu T: 


eret. We show that 


(A) e(n’) =0 
(B) Yo € Prefix(n’).c(0) 20 


This implies that 7’ € Bal(E) by Lemma 5.6. 
(A) Since n € Bal(E) we have c(7) = 0. This implies 
er’) = clecaı) + (tt) + cleret) = 1+e(m) + (-1) =1+0 + (-1) =0. 
(B) Let 9 € Prefix(n’). The case 0 = n’ is already covered by (A). Also, 
c(e) = 0 holds by definition. It remains the case that 0 = e..ı] 0’ for some 
prefix 6’ of n. But n € Bal(E), which implies c(6’) > 0 by Lemma 5.6. It 
follows 
c(O) = c(ecan 0°) = cca) + cl) = 1+ ¢(8") > 0. 
oO 


Theorem 5.19. Bal(E) is the least subset X of E* with the following properties: 


TEX e € Ejntra 


Ball)—— (Ball 
G Sex (Pa ) Te EX 


TEX nm eX Ccall E Ecall eret © Eret 
i) eee 
Tl Eoall TU" Cret € x 


Proof. First, we show that Bal(E) satisfies the properties Bal1, Bal2, Bal3. It 
is clear that Bal(E) satisfies Ball. Furthermore, Lemma A.2, Lemma A.3 
and Lemma A.4 imply that it also has the properties Bal2 and Bal3. 
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A.3 Proof of Theorem 5.19 


It remains to show that Bal(E) is the least subset of E* with properties Bal1, 
Bal2, Bal3. For this, let X C E* be a set of symbol sequences that satisfies 
the closure properties Ball, Bal2 and Bal3. We show Bal(E) © X by strong 
induction on the lengths of symbol sequences. The induction hypothesis 
forn € Nis 


(A.2) Yr € Bal(E) |n| <n => neX 


Now let n € Bal(E), |n| = n. We show n € X by a case distinction on 
whether Retpos(7) = ® or not. 


1. If Retpos(n) = Ø, then we also have Callpos(m) = 0, because 7 is 
balanced. Hence, 7 is either empty or solely consists of intraprocedural 
symbols. Thus, 7 € X can be derived by repeated application of Ball and 
Bal2. 


2. If Retpos(r) + @, then let j be the maximum of Retpos(r). Since n is 
def ; 
balanced, there must be i € range(r) with (i, j) € vn. With ecaj 2 m’ and 


de ; i 
eret = TJ, T can be decomposed into 


From (i, j) € vz it follows that rl" is balanced. From this, the balanced- 
ness of 7 and the choice of j, we can conclude by application of Lemma A.1 
that both rn“ and 17! are balanced. 


Since both mand rll are balanced and shorter than n, we obtain m<! € X 
and ri il € X by induction hypothesis. With Bal3 we get 


(A.3) ni. Ecall * iil ' eret E X 
Due to the choice of j, we have Retpos(n”/) = Ø. Since n?! is balanced, 
this implies that Callpos(m7/) = ®, too. Hence, from (A.3) we get 

ne . Ecall . Wil . Cret . wi € X 


by repeated application of Bal2. 
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A.4 Proof of Theorem 5.20 


Definition A.5. For a given symbol sequence n € E*, we define the set MRet (ri) 
of matched return positions as follows: 


I; 


MRet(r) f j  Retpos(n) | di € range(n). (i, j) € Vn} 


Lemma A.6. Let n € Left(E) such that MRet(n) # 0. Assume that j is the 
greatest element of MRet and let i = v}! (j). Then the following statements hold: 


1. Both n“! and n>! are left-total. 
2. nÍ consists only of symbols from Ejytra U Eret 
Proof. We show the two statements separately. 


1. Let i’ € Callpos(n<'). Because Callpos(n“) © Callpos(n) and n € 
Left(E), we find j’ € range(n) with (i, j’) € vn. This j’ is a member 
of MRet(n): j’ € MRet(7). Due to the choice of j, we have j’ < j. With 
Theorem 5.10 and i’ < i we get j’ <i. Therefore, (i’, j’) € v, <i: This shows 


n“ e Left(E). 
2. This is an easy consequence of the maximality of j. 
m) 


Theorem 5.20. Left(E) is the least subset X of E* which has the following 
properties: 


TEX e € Ejntra U Eret 


(Left1) (Left2) 


EE Te EX 


TEX n E Bal (E) ecall € Ecall eret € Eret 


(Left3) 


Tl * ecall © n -eret E X 


Proof. First, we observe that Left(E) has the closure properties Left1, 
Left2, Left3. This is clear for Le ft1, the other two properties follow from 
Lemma A.2, Lemma A.3, Lemma A.4 and Remark 5.12. 

Next, let X C E* be a set with the closure properties Le ft1, Left2 and Le ft3. 
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A.4 Proof of Theorem 5.20 


Now we show Left(E) < X by strong induction on the length of sequences 
from E*. 
For n € N, the induction hypothesis is 


(A.4) VreE* |n|<nAneéLeft(E) => neX 


Now let n € E* be a symbol sequence with |n| = n and n € Left(E). We 
show nr € X by case distinction on whether MRet (7) = 0 or not. 


1. If MRet(r) = Ø, then Callpos(rt) must be empty, too: Assume, for the 
purpose of contradiction, that Callpos(7) contains some call position i. 
Then i cannot be matched, because MRet(r) = Ø. But this is a contradiction 
to m € Left(E). Hence, the assumption is false and Callpos(n) = 0. 


Because Callpos(m) = Ø, n solely consists of symbols from Ejytra U Eret- 
Hence, rn € X can be derived by repeated application of Leftl and Le ft2. 


2. If MRet(n) + @, then let j be the greatest element of MRet(7) and 


; Penner def _; def _; 
i= v3! (j). With econ = re and eret =) TJ, n can be written as 
T = nt G Ecall s niil x eret N nÍ 


By definition, rl is balanced. Plus, since € Le ft(E) and due to the choice 
of j, by application of Lemma A.6 we obtain n“ € Left(E), m7! € Left(E) 
and that 77! consists only of symbols from Ejytra U Eret- 


Equipped with these observations, we can finish the proof as follows: 


a) Because rama < |n| and n“! € Left(E), we may apply (A.4) to 7<! and 
obtain that n“ € X. 


b) Now we apply Left3 to n“ e X, nlil e Bal (E), eca € Ecay and eret € Eret 
and get Te ecl: ntl. eret E X. 


c) Finally, because nÍ € (Ejntra U Eret)*, we obtain 
nt . Ccall . Wil . eret . nÍ E X 


by repeated application of Left2 to n“ + ecn: Wil - eret € X. 
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A.5 Proof of Theorem 5.21 
Lemma A.7. 1. If n € Left(E) and n>% is a suffix of n, then n>% € Left(E). 
2. If m € Right(E) and n“] is a prefix of n, then n</ € Right(E). 


Proof. 1. Consider an arbitrary n € Left(E) and let m2* be a suffix of n. 
We need to show that v „>x is left-total. Let i € Callpos(n2*). Then we show 
that there is j € Retpos(n2*) such that (i, j) € Vak- 


First, we observe (nk)! = n“ti. Hence, we have i +k € Callpos(r). 
Because vz is left-total, there is j’ € Retpos(m) such that (i + k, j’) € vn. 
Moreover, because j’ > k +i > k, we can write j’ as j’ = (j’-—k) +k. In 
particular, we have j’ — k € range(n*). With Lemma 5.17, it follows from 
(i +k, (f-k) +k) € vn that (i, j’ —k) € v 2x, which concludes the proof. 


2. Letn € Right(E) and n“] be a prefix of n. Let 
l € Retpos(n“]) c Retpos(r) 


be a return position in rn“). Due to right-totality of vz, we find a k € 
Callpos(7) such that (k,l) € vn. This means in particular that k < l. With 
l < j we get k < j so that we can conclude (k,1) € v_<j. This proves that 
v sj is right-total. 

DO 


Lemma A.8. Let n € Right(E) such that Retpos(m) + Ø. Assume that j is the 
greatest element of Retpos(rı) and let i = v71 (j). Then both n“' € Right(E) and 
m7) € Right(E). 


Proof. Since j is the greatest return position, we have Retpos(n”!) = 0. 
Hence, n”] can only consist of symbols from Ejytra U Eca, so that Wie 
Right(E) holds trivially. Furthermore, n“ € Right(E) holds because 
Right(E) is closed under prefixes (by Lemma A.7). m) 
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A.5 Proof of Theorem 5.21 


Theorem 5.21. Right(E) is the least subset X of E* which has the following 
properties: 


MER e € Eintra U E cay 


(Right1) (Right2) 


ee Te EX 


neX n’eBal(E en EE I: 
Ging) ES NE en 2 ee 
TU: ecall Te * eret € X 


Proof. First, we observe that Right(E) has the closure properties Right1, 
Right2, Right3. This is clear for Right1, the other two properties follow 
from Lemma A.2, Lemma A.3, Lemma A.4 and Remark 5.12. 

Next, let X C E* be a set with the closure properties Right1, Right2 and 
Right3. We show Right(E) C X by strong induction on the length of 
sequences from E*. 

For n € N, the induction hypothesis is 


(A.5) VneE*.n|<naneRight(E) => neX 


Now let n € E* be a symbol sequence with |n| = n and n € Right(E). We 
show nr € X by case distinction on whether Retpos(7) = Ø or not. 


1. If Retpos(1) = 0, then 7 does not contain any return symbols. Hence, 
mt is either empty or solely consists of symbols from E;ntra U Ecan- In both 
cases, 71 € X can be derived by repeated application of Right1 and Right2. 


2. If Retpos(r) + 0, then let j be the greatest element of Retpos(m) and 
def . 
i = v3}! (j). This is well-defined because n € Right(E). With esal 2 m and 


de . A 
Eret 2 TJ, n can be written as 
n= n egg: niil ee n 


By definition, nl’ is balanced. Plus, since n € Right(E) and due to the 
choice of j, application of Lemma A.8 yields that n“ € Right(E). 
Now we can finish the proof as follows: 


a) Because In“) < |n| and “Í € Right(E), we may apply (A.5) to n“ and 
obtain that n“ € X. 
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b) Now we apply Right3 to n“ e X, nlil € Bal(E), eg € Eat) and 
eret € Eret and get us call ` nid. eret E X. 


c) Finally, we note that, due to the choice of j, nÍ only contains symbols 
from Ejntra U Ecay. Hence, we obtain 


net . Ecall . Wil . Cret . nw! € X 


by repeated application of Right2 to n“ + eoq «THI - eret € X. 


A.6 Proof of Lemma 5.24 


Lemma A.9. For n € E* and e € E, we have vre = vr if one of the following 
conditions is satisfied: 


(i) ee Eintra U Ecall 
(ii) e € Exe AT € Left(E) 


Proof. By definition, it is clear that vz < v7z.¢. For the other inclusion we 
assume either condition and show that vz.e < Vn holds in both cases. 


(i) Assume thate € Ejntyg U Ecqy. Let (i, j) € Vre. Then i < j and (n-e) e 
Eet. Since Eye N (Eintra U Eca) = 0, (n g e)! € Erret implies that j + |r]. 
Hence j € range(r). But with i < j this means that i € range(m). Hence 
(i,j) E vr. 


(ii) Assume e € E, and n € Left(E). Let (i,j) € Vne. From (i,j) € Vre 
we geti < j so that i € range(m). Moreover, n € Left(E), hence there is 
j € range(m) with (i, j’) € vn S Vre. From Theorem 5.8, we get j = j’ and 
thus (i, j) € vn. 


(m 
Lemma 5.24. 1. [fm € AscSeq(E) ande € Ejntra U Eret, then m-e € AscSeq(E). 
2. If m € DescSeq(E) and e € Eintra U Ecay, then T- e € DescSeq(E). 
3. If n € SLSeq(E) and e € Eiņtra, then m-e € SLSeq(E). 
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A.7 Proof of Lemma 5.25 


Proof. 1. Let n € AscSeq(E) and e € Eintra U Eret-: Then n € Left(E) NA 
Val(E). It follows that n -e € Left(E) by Theorem 5.20. Moreover, Vre = Vx 
by Lemma A.9. Thus, m- e € Val(E) follows from n € Val(E). 


2. Let n € DescSeq(E) and e € Eintra U Ecay. Then n € Right(E) N Val(E). 
It follows that m -e € Right(E) by Theorem 5.21. Moreover, Vre = Vr by 
Lemma A.9. Thus, validness of n - e follows from validness of n € Val(E). 


3. This follows from a combination of the first two statements. 


A.7 Proof of Lemma 5.25 

Lemma 5.25. Letn € Val(E) and n’ € SLSeq(E). Then the following statements 
hold: 

1. nn’ is valid. 

2. If r € Bal(E), then m- n’ is same-level. 

3. If € Left(E), then nn’ is ascending. 

4. If m € Right(E), then nT- n’ is descending. 

Proof. 


The first statement can be seen as follows: Let (i, j) € v„.„. Then either 
j € range(n) or there is j’ € range(n’) with j = |n| + j’. We show that 
(i, j) € P in either case. 


1. Assume j € range(n). Then i € range(n) since i < j. Furthermore we 
have (i, j) € vz by definition of vy. This entails (i, j) € ® because 7 is valid. 


2. Assume that j = |n| + j’ for j’ € range(n’). Since n’ is balanced and 
hence right-total, there is i’ € range(n’) with (t, j’) € vw. By Lemma 5.17, 
this means that (t + |n|, j) € Vn and because vy. is right-unique, it 
follows that i = i’ + |n’|. Since nr’ is valid, we get 


(rn: n'y, (T: n’)/) =- (n, nl’) EÈ. 


The other three statements are implied by the first statement and Lemma A.3 
after noticing that SLSeq(E) < Bal(E), SLSeq(E) < Left(E) and SLSeq(E) < 
Right(E), respectively. o 
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A.8 Proof of Lemma 5.26 


Lemma 5.26. If n € SLSeq(E), eca € Ecall» eret € Eret and (eca, eret) € ®, 
then ecall ` Te eret € SLSeq(E). 


Proof. Define n’ ia Ecall ` T+ eret. From 7 € Bal(E), Ccall € Ecall eret € Eret, 
we conclude that n’ € Bal(E) by Lemma A.4. It remains to show that 
n’ € Val(E). Let (i,j) € vw. Then we show by case distinction on whether 
i = 0 or not that (rf, nÍ) € ®. 


1. If i = 0, then we must have j = |n’|- 1: Since vw is left-unique by 
Theorem 5.8, there can be only one j with (0, j) € vw. Furthermore, by 
definition of vz”, we have (0, |r|- 1) € vw: 

e We have 0 < |n’| - 1, since |r’| > 2. 


rr’ |-1 


e We have n”? = eo € Ecaj and 1 = lret € Eret 


© We have m’ WI — n € Bal(E) by assumption. 
Thus (nt, i) = (1/9, mel) = (eca eret) € ® by assumption. 
2. Assume i # 0. Then i € [1,|n’|- 1[ because n’ € Eggi and m 1 € Eet 
and Eq N Eret = 0. Furthermore, j €]1,|7’|-1[: j > 1 follows from 0 < i 
and i < j. Moreover, since v is right-unique and (0, |n’|-1) € vz and 
i + 0, we have j # |n’|-1. Hence, by Lemma 5.17 and because r is valid, 
we get (n,n!) € ®. 
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| report on applications of slicing and program dependence 


graphs (PDGs) to software security. Moreover, | propose 


a 


framework that generalizes both data-flow analysis on con- 
trol-flow graphs and slicing on program dependence graphs. 
Such a framework enables to systematically derive data- 
flow-like analyses on program dependence graphs that go 


beyond slicing. 


The main theses of my work are: 

1. PDG-based information flow control is useful, 
practically applicable and relevant. 

2. Data-flow analysis can be systematically applied to 
program dependence graphs. 


3. Data-flow analysis on PDGs can be practically conducted. 
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